セキュリティの管理

セキュリティの管理

セキュリティの管理

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

•

セキュリティの管理とは

•

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

•

Oracle Tuxedoレジストリの設定

•

セキュリティ用のATMIアプリケーションの構成

•

管理環境の設定

•

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

•

認証の管理

•

プリンシパル名の指定

•

相互運用性のポリシーの指定

•

ドメイン間のリンクの確立

•

ACLポリシーの設定

•

資格証明ポリシーの設定

•

認可の管理

•

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

•

SSL暗号化の管理

•

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

•

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

•

Kerberos認証プラグインの使用

•

Kerberosプラグイン

•

Kerberosプラグインの事前構成

•

Kerberosプラグインの構成

•

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

•

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

•

Cert-C PKI暗号化プラグインの事前構成

•

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

セキュリティの管理とは

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

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

•

認証

•

認可

•

監査

•

リンク・レベルの暗号化

•

SSL暗号化

•

公開鍵によるセキュリティ機能

アプリケーション管理者はセキュリティ機能を構成できます(ただし、例外が1つあります)。その例外は監査で、図2-1に示すように監査は構成できません。

図2-1 ATMIのセキュリティの管理

関連項目

•

2-4ページの「セキュリティ管理のタスク」

•

1-2ページの「セキュリティとは」

•

3-1ページの「セキュリティのプログラミングとは」

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

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

•

Oracle Tuxedoレジストリの設定

•

セキュリティ用のATMIアプリケーションの構成

•

管理環境の設定

•

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

•

認証の管理

•

認可の管理

•

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

•

SSL暗号化の管理

•

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

•

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

関連項目

•

2-4ページの「Oracle Tuxedoレジストリの設定」

Oracle Tuxedoレジストリの設定

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

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

Oracle Tuxedoレジストリの目的

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

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

•

UNIXホスト・マシンの場合、Oracle Tuxedoレジストリは$TUXDIR/udataobjディレクトリにあります。

•

Windows 2003ホスト・マシンの場合、Oracle Tuxedoレジストリは%TUXDIR%\udataobjディレクトリにあります。

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

プラグインの登録

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

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

•

epifreg - プラグインの登録

•

epifunreg - プラグインの登録解除

•

epifregedt - レジストリ情報の編集

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

セキュリティ・プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。

関連項目

•

2-6ページの「セキュリティ用のATMIアプリケーションの構成」

セキュリティ用のATMIアプリケーションの構成

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

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

•

構成ファイル(UBBCONFIG)を編集する

•

TM_MIBの変更

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

構成ファイルの編集

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

UBBCONFIGファイルおよびTUXCONFIGファイル(バイナリ形式の構成ファイル)の詳細は、『Oracle Tuxedoアプリケーションの設定』の構成ファイルに関する項および構成ファイルの作成に関する項を参照してください。

TM_MIBの変更

TM_MIBでクラスのセットを定義することにより、ATMIアプリケーションの基本的な側面を構成し、管理することができます。クラスは、マシン、サーバー、ネットワークなど、コンポーネントごとに指定されます。管理リクエストの形式および管理応答の解釈については、TM_MIB(5)のリファレンス・ページと、汎用的な管理情報ベース(MIB: Management Information Base)のリファレンス・ページであるMIB(5)の両方を参照してください。MIBのリファレンス・ページは、『Oracle Tuxedoファイル形式、データ記述、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の詳細は、まず『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のMIB(5)に関する項を参照してください。『Oracle Tuxedo ATMIの紹介』も参照してください。

関連項目

•

2-7ページの「管理環境の設定」

管理環境の設定

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

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

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

関連項目

•

2-8ページの「オペレーティング・システム(OS)セキュリティの管理」

•

2-9ページの「認証の管理」

•

2-34ページの「認可の管理」

•

2-35ページの「リンク・レベルの暗号化の管理」

•

2-40ページの「SSL暗号化の管理」

•

2-52ページの「公開鍵セキュリティの管理」

•

2-4ページの「セキュリティ管理のタスク」

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

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

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

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

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

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

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

•

ファイルおよびIPCリソースに対するアクセスをアプリケーション管理者に制限します。

•

setuidユーティリティを使用して、信頼性のあるクライアント・プログラムを必ず管理者のパーミッションで実行します。

•

最も高いレベルのオペレーティング・システムのセキュリティを実現するには、ワークステーション・クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション・サーバーおよび管理プログラムを実行するマシンではクライアント・プログラムを実行できないようにします。

•

前述のすべての方法をATMIのセキュリティと組み合せて使用し、リクエストの発行元であるクライアントをアプリケーション側で識別できるようにします。

関連項目

•

1-6ページの「オペレーティング・システム(OS)のセキュリティ」

•

2-4ページの「セキュリティ管理のタスク」

認証の管理

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

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

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

図2-2 高信頼性委任型認証モデルでの相互認証

注意:

相互認証は、ネイティブ・クライアントには適用されません。ネイティブ・クライアントを認証するのは、ネイティブ・クライアント自身です。

次は、前述の図の構成の設定に必要な操作の一覧です。すべての操作で、認証と認可のプラグインが必要になります。

•

プリンシパル名の指定

•

相互運用性のポリシーの指定

•

ドメイン間のリンクの確立

•

ACLポリシーの設定

•

資格証明ポリシーの設定

関連項目

•

1-7ページの「認証」

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

•

1-53ページの「セキュリティの相互運用性」

•

1-58ページの「セキュリティの互換性」

•

『Oracle Tuxedo ATMIの紹介』のOracle Tuxedo Domains(複数ドメイン)サーバーに関する項

プリンシパル名の指定

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

パラメータ名

説明

設定

UBBCONFIGのSEC_PRINCIPAL_NAME (TM_MIBのTA_SEC_PRINCIPAL_NAME)

アプリケーションの起動時に、ATMIアプリケーション内のそれぞれのWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスは、認証プラグインを呼び出して、SEC_PRINCIPAL_NAMEで指定されたセキュリティ・プリンシパル名のセキュリティ資格証明を取得します。*

1から511文字。プリンシパル名が構成階層のどのレベルでも指定されない場合は、UBBCONFIGファイルのDOMAINIDの文字列がデフォルト値になります。

ローカル・ドメイン・アクセス・ポイントを示すDMCONFIGのCONNECTION_PRINCIPAL_NAME (DM_MIBにあるLACCESSPOINTのTA_DMCONNPRINCIPALNAME)

アプリケーションの起動時に、ATMIアプリケーション内の各ドメイン・ゲートウェイ・プロセスは、認証プラグインをもう一度呼び出して、CONNECTION_PRINCIPAL_NAMEで指定された接続プリンシパル名のセキュリティ資格証明を取得します。*

1から511文字。接続プリンシパル名を指定しない場合は、DMCONFIGファイルで指定されたローカル・ドメイン・アクセス・ポイントを示すACCESSPOINTID **の文字列がデフォルト値になります。

* システム・プロセスが資格証明を取得する方法、および資格証明が必要な理由については、次の項で説明します。

**ACCESSPOINTIDパラメータはDOMAINIDともいいます。

SEC_PRINCIPAL_NAMEは、構成の階層のうち、次の4つのレベルのどこでも指定できます。

•

UBBCONFIGファイルのRESOURCESセクション、またはTM_MIBのT_DOMAINクラス

•

UBBCONFIGファイルのMACHINESセクション、またはTM_MIBのT_MACHINEクラス

•

UBBCONFIGファイルのGROUPSセクション、またはTM_MIBのT_GROUPクラス

•

UBBCONFIGファイルのSERVERSセクション、またはTM_MIBのT_SERVERクラス

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

•

serv1以外の、mach1上のすべてのWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスは、プリンシパル名としてterriを使用します。

•

serv1のすべてのプロセスは、プリンシパル名としてjohnを使用します。

注意:

セキュリティ・プリンシパル情報は、ネットワーク・アプリケーション(MPモード)構成のすべてのマシンに指定する必要があります。起動エラーが発生する場合は、エラーの原因について、エラーが発生した接続の両側のULOGファイルを確認してください。

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

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

図2-3 アプリケーションの起動時に資格証明とトークンを取得する

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

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

WSHには資格が必要です。資格があれば、ワークステーション・クライアントを認証してアプリケーションに参加させ、認証されたワークステーション・クライアント用の認可トークンと監査トークンを取得することができます。WSHがリリース7.1より前のクライアント(Oracle Tuxedo 6.5以前のソフトウェアで動作するクライアント)からのリクエストを処理する場合、このWSHには、WSH自身の認可トークンと監査トークンが必要です。これらのトークンがあれば、WSHは認証プラグインを呼び出して、古いバージョンのクライアントのIDを確認できます。この動作については、2-15ページの「相互運用性のポリシーの指定」を参照してください。

ドメイン・ゲートウェイにも一組の資格が必要です。資格を取得すると、2-24ページの「ドメイン間のリンクの確立」で説明するように、リモート・ドメイン・ゲートウェイを認証し、ATMIアプリケーション間でリンクを確立できます。認証されたリモート・ドメイン・ゲートウェイには、認可トークンも監査トークンも割り当てられません。ドメイン・ゲートウェイは、CONNECTION_PRINCIPAL_NAMEパラメータで指定されたプリンシパル名で、これらの資格を取得します。

ドメイン・ゲートウェイがリリース7.1より前のクライアントからのリクエストを処理する場合、つまり、認証プラグインを呼び出して、古いバージョンのクライアントのIDを確認する場合、このドメイン・ゲートウェイにはもう一組の資格証明が必要です。この動作については、2-15ページの「相互運用性のポリシーの指定」を参照してください。これらの資格証明は、ローカルのアクセス制御リスト(ACL: Access Control List)を適用する場合にIDを確認するときにも必要です(2-29ページの「ACLポリシーの設定」を参照)。ドメイン・ゲートウェイは、SEC_PRINCIPAL_NAMEパラメータで指定されたプリンシパル名で、これらの資格証明を取得します。

システムまたはアプリケーション・サーバーがリリース7.1より前のクライアントからのリクエストを処理する場合は、システムまたはアプリケーション・サーバー自身の認可トークンと監査トークンが必要です。これらのトークンがあれば、認証プラグインを呼び出して、古いバージョンのクライアントのIDを確認できます。この動作については、2-15ページの「相互運用性のポリシーの指定」を参照してください。

サーバーは、サーバー・パーミッションのアップグレードを行うときにもサーバー自身のトークンを必要とします。サーバー・パーミッションのアップグレードは、クライアントから発信されサーバーを経由して送信されるメッセージに対し、認可トークンおよび監査トークンが割り当てられるときに発生します。サーバーのアップグレード機能については、1-10ページの「クライアント・トークンとサーバー・トークンの交換」を参照してください。

注意:

アプリケーション・サーバーは、認証プラグインを呼び出すことはできません。アプリケーション・サーバーの認証プラグインは、基底のシステム・コードによって呼び出されます。

プリンシパル名を指定するUBBCONFIGのエントリ例

次の例は、UBBCONFIGのSEC_PRINCIPAL_NAMEパラメータを使用してセキュリティ・プリンシパル名を指定する方法を示しています。CONNECTION_PRINCIPAL_NAMEパラメータを使用して、DMCONFIGファイルの接続プリンシパル名を指定する例については、2-27ページの「リンクを確立するためのDMCONFIGのエントリ例」を参照してください。
*RESOURCES
SEC_PRINCIPAL_NAME    "Tommy"
     .
     .
     .
*SERVERS
"TMQUEUE"       SRVGRP="QUEGROUP"      SRVID=1
   CLOPT="-t -s secsdb:TMQUEUE"
   SEC_PRINCIPAL_NAME="TOUPPER"
関連項目

•

2-15ページの「相互運用性のポリシーの指定」

•

2-24ページの「ドメイン間のリンクの確立」

•

で2-29ページの「ACLポリシーの設定」

•

2-4ページの「セキュリティ管理のタスク」

相互運用性のポリシーの指定

管理者は、UBBCONFIGファイルのCLOPT -tオプションを使用して、ATMIアプリケーション内のWSH、ドメイン・ゲートウェイ(GWTDOMAIN)およびサーバー・プロセスが、Oracle Tuxedoリリース7.1より前(6.5以前)のソフトウェアを実行しているマシンと相互運用するように指定できます。また、WSINTOPPRE71環境変数を使用して、ワークステーション・クライアントがOracle Tuxedoリリース7.1より前のソフトウェアを実行するマシンと相互運用するよう指定できます。次に、これらのプロセスの相互運用性を説明する4つの図を示します。

図2-4 新しいWSHと古いワークステーション・クライアントの相互運用

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

注意:

ユーザー偽装関数は、認証プラグインを呼び出して、古いクライアントのIDを確立します。詳細は、2-19ページの「古いクライアントのIDの確認」を参照してください。

図2-5 古いWSHと新しいワークステーション・クライアントの相互運用

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

図2-6 サーバーと古いATMIアプリケーションの相互運用

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

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

図2-7 サーバーと古いOracle Tuxedoシステムの相互運用

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

注意:

また、上の図で、マシン1のWSHがマシン2のサーバー宛てのクライアント・リクエストを受け取ると、WSHはリクエストに添付されたトークンを取除いてから、そのリクエストをクライアントのアプリケーション・キーとともにマシン2のサーバーに送信します。同様に、マシン1のネイティブ・クライアントがマシン2のサーバーにリクエストを送信した場合、ネイティブ・クライアントは、リクエストに添付されたトークンを取除いてから、そのリクエストをクライアントのアプリケーション・キーとともにマシン2のサーバーに送信します。アプリケーション・キーについては、1-48ページの「アプリケーション・キー」を参照してください。

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

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

図2-8 古いクライアントの認可トークンと監査トークンの取得

WSH側で古いクライアントのIDを確認する

CLOPT -tオプションが指定されている場合、WSHは、TPINITバッファのusrnameフィールドを使用するか(Cの場合)、またはTPINFDEF-RECレコードのUSRNAMEフィールドを使用して(COBOLの場合)古いクライアントのIDを確認します。3-7ページの「ATMIアプリケーションへの参加」で説明するとおり、クライアントがアプリケーションに参加しようとすると、WSHはクライアントからTPINITバッファまたはTPINFDEF-RECレコードを受け取ります。WSHは、ユーザー偽装関数を呼び出すときにプリンシパル名としてユーザー名を使用します。

デフォルトの認証プラグインの場合、ユーザー偽装関数は、ローカルのtpusrファイルからユーザー名および関連するアプリケーション・キー(ユーザー識別子とグループ識別子の組合せ)を検索し、古いクライアント用に作成された認可トークンと監査トークンに、ユーザー名とアプリケーション・キーを両方とも組み込みます。tpusrファイルについては、2-70ページの「ユーザー・ファイルとグループ・ファイルの設定」を参照してください。

ドメイン・ゲートウェイ側で古いクライアントの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、ドメイン・ゲートウェイ、およびサーバー・プロセスの機能をまとめたものです。

表2-1 相互運用性を実現できる場合または実現できない場合のWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスの機能

プロセス

相互運用性を実現できる場合(CLOPT -t)

相互運用性を実現できない場合

ワークステーション・ハンドラ(WSH)

WSHは、アプリケーションに参加するためのリクエストをリリース7.1より前のワークステーション・クライアントから受け取ると、リリース7.1より前の認証プロトコルを使用してクライアントを認証します。次に、リクエスト内で指定されているユーザー名に基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンと監査トークンを取得します。

WSHは、認証されたワークステーション・クライアントからサービス・リクエストを受け取ると、クライアント・リクエストにトークンを添付し、リクエスト先のサーバーに転送します。

WSHは、アプリケーションに参加するためのリクエストをリリース7.1より前のワークステーション・クライアントから受け取っても拒否します。新しいWSHと古いワークステーション・クライアントとの間の通信は実現できません。

ドメイン・ゲートウェイ(GWTDOMAIN)

ドメイン・ゲートウェイは、リリース7.1より前のリモート・ドメイン・ゲートウェイとの接続を確立すると、リリース7.1より前の認証プロトコルを使用してそのリモート・ドメイン・ゲートウェイを認証し、ネットワーク接続を確立します。

ドメイン・ゲートウェイは、古いドメインからのクライアント・リクエストを受け取ると、リモート・ドメイン・アクセス・ポイントに構成されたLOCAL_PRINCIPAL_NAME (デフォルトはACCESSPOINTID)のID に基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンおよび監査トークンを取得します。次に、これらのトークンをクライアント・リクエストに添付し、リクエスト先のサーバーに転送します。クライアントには、LOCAL_PRINCIPAL_NAME IDと同じアクセス・パーミッションがあります。

アウトバウンドのクライアント・リクエストの場合、ドメイン・ゲートウェイは、リクエストに添付されたトークンを取除いてから、そのリクエストをアプリケーション・キーとともに古いドメインに送信します。

ドメイン・ゲートウェイは、7.1より前のリリースのリモート・ドメイン・ゲートウェイとの接続を設定しません。新しいドメインと古いドメインとの間の通信は実現できません。

システムまたはアプリケーション・サーバー

サーバーは、リリース7.1より前のOracle Tuxedoソフトウェアを実行するリモート・クライアントからリクエストを受け取ると、クライアントに割り当てられたアプリケーション・キーに基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンと監査トークンを取得します。次に、サーバーは、クライアントが認可チェックにパスしたとみなしてクライアント・リクエストを実行します。

サーバーは、Oracle Tuxedoリリース7.1より前のソフトウェアを実行するリモート・クライアントからリクエストを受け取っても拒否します。新しいサーバーと古いクライアントとの間の通信は実現できません。

相互運用性を指定するUBBCONFIGのエントリ例

次の例は、ワークステーション・リスナー(WSL)によって制御されるすべてのWSHで相互運用性が実現できることを示しています。
*SERVERS
WSL    SRVGRP="group_name" SRVID=server_number ...
       CLOPT="-A -t ..."
関連項目

•

2-10ページの「プリンシパル名の指定」

•

2-24ページの「ドメイン間のリンクの確立」

•

で2-29ページの「ACLポリシーの設定」

•

2-4ページの「セキュリティ管理のタスク」

•

1-53ページの「セキュリティの相互運用性」

•

『Oracle Tuxedo Domainsコンポーネントの使用』の「ドメイン構成のセキュリティの設定」および「ドメイン構成の接続の設定」

ドメイン間のリンクの確立

ドメイン・ゲートウェイ(GWTDOMAIN)が別のドメイン・ゲートウェイとのネットワーク・リンクを確立しようとすると、次のようなイベントが発生します。

1.

イニシエータおよびターゲットのドメイン・ゲートウェイは、SSLまたはリンクレベル暗号化(LLE)のmin-max値を交換します。これらの値は、ゲートウェイ間のリンクにSSLまたはLLEを設定するために使用されます。SSLを使用している場合は、イニシエータおよびターゲットのドメイン・ゲートウェイも、SSL証明書を使用して相互に認証し合います。

LLEについては、1-22ページの「リンク・レベルの暗号化」を参照してください。SSLについては、1-26ページの「SSL暗号化」を参照してください。

2.

イニシエータおよびターゲットのドメイン・ゲートウェイは、セキュリティ・トークンを交換することにより、認証し合います。このとき、双方でOracle Tuxedoリリース7.1以上のソフトウェアを実行していると想定します。

どちらかまたは両方のドメイン・ゲートウェイがOracle Tuxedoリリース7.1より前のソフトウェアを実行している場合、ゲートウェイ・プロセスでは、リリース7.1より前の古い認証プロトコルを使って接続が確立されます。

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

パラメータ名

説明

設定

DMCONFIGのCONNECTION_PRINCIPAL_NAME (DM_MIBのTA_DMCONNPRINCIPALNAME)

このパラメータがDMCONFIGファイルのDM_LOCALセクション*にある場合、リモート・ドメイン・アクセス・ポイントとの接続を設定する際のこのパラメータの値は、ローカル・ドメイン・アクセス・ポイントのプリンシパル名になります。

デフォルトの認証プラグインで、ローカル・ドメイン・アクセス・ポイントのCONNECTION_PRINCIPAL_NAMEに値を割り当てる場合、その値は、ローカル・ドメイン・アクセス・ポイントのACCESSPOINTIDパラメータ*の値と同じでなければなりません。これらの値が一致しないと、ローカル・ドメイン・ゲートウェイ・プロセスが起動せず、次のuserlog(3c)メッセージが生成されます。ERROR:クレデンシャルを取得できません。

1から511文字。指定しない場合は、ローカル・ドメイン・アクセス・ポイントのACCESSPOINTID文字列がデフォルト値になります。

このパラメータがDMCONFIGファイルのDM_REMOTEセクション*にあり、特定のリモート・ドメイン・アクセス・ポイントを示す場合、ローカル・ドメイン・アクセス・ポイントとの接続を設定する際のこのパラメータの値は、リモート・ドメイン・アクセス・ポイントのプリンシパル名になります。

デフォルトの認証プラグインで、リモート・ドメイン・アクセス・ポイントのCONNECTION_PRINCIPAL_NAMEに値を割り当てる場合、その値は、リモート・ドメイン・アクセス・ポイントのACCESSPOINTIDパラメータ*の値と同じでなければなりません。これらの値が一致しないと、ローカル・ドメイン・ゲートウェイとリモート・ドメイン・ゲートウェイの接続は失敗し、次のuserlog(3c)メッセージが生成されます。ERROR:ドメインdomain_nameの管理用キーを初期化できません。

1から511文字。指定しない場合、リモート・ドメイン・アクセス・ポイントのACCESSPOINTID文字列がデフォルト値になります。

*DM_LOCALセクションはDM_LOCAL_DOMAINS、DM_REMOTEセクションはDM_REMOTE_DOMAINS、ACCESSPOINTIDパラメータはDOMAINIDともいいます。

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

図2-9 デフォルトの認証を使用してドメイン間にリンクを確立する

注意:

前述の図の「資格証明」は、ローカル・ドメイン・アクセス・ポイントに対して構成されたCONNECTION_PRINCIPAL_NAMEのIDを使用して、アプリケーションの起動時に、各ドメイン・ゲートウェイ・プロセスによって取得されます。

上の図で、イニシエータおよびターゲットのドメイン・ゲートウェイ間で交換される情報には、ドメイン・ゲートウェイ用に構成されたBDMCONFIGファイルのCONNECTION_PRINCIPAL_NAME文字列が含まれる点に注目してください。各認証プラグインは、リモート・ドメイン・アクセス・ポイントに割り当てられたパスワード(BDMCONFIGファイルのDM_PASSWORDSセクションで定義)を使用して文字列を暗号化してから、それをネットワーク経由で送信し、ローカル・ドメイン・アクセス・ポイントに割り当てられたパスワード(BDMCONFIGファイルのDM_PASSWORDSセクションで定義)を使用して受信した文字列を復号化します。このとき、暗号化アルゴリズムとして、56ビットのDES (Data Encryption Standard)が使用されます。

暗号化および復号化の操作を成功させるため、ローカルのBDMCONFIGファイルで指定された、リモート・ドメイン・アクセス・ポイント用のパスワードは、リモートのBDMCONFIGファイルで指定されたローカル・ドメイン・アクセス・ポイント用のパスワードと同じでなければなりません。同様に、ドメインのセキュリティ・レベルがAPP_PWに設定されている場合に暗号化および復号化の操作を成功させるには、各TUXCONFIGファイルのアプリケーション・パスワードが同じでなければなりません。認証プロセスを成功させるには、受信した文字列が、送信者のCONNECTION_PRINCIPAL_NAME文字列と一致しなければなりません。

ドメイン・ゲートウェイがセキュリティ・チェックにパスすると、リンクが確立され、ゲートウェイは、確立されたリンクを介してサービス・リクエストを転送したり、応答を受信することができます。

リンクを確立するためのDMCONFIGのエントリ例

次の例は、ローカル・ドメイン・アクセス・ポイントc01と、リモート・ドメイン・アクセス・ポイントb01を使って接続を確立するときに、ローカルのDMCONFIGファイルの構成が使用されることを示しています。
*DM_LOCAL
# <local domain access point name> <gateway group name> <domain type> 
# <domain id> [<connection principal name>] [<security>]...
c01    GWGRP=bankg1
       TYPE=TDOMAIN
       ACCESSPOINTID="BA.CENTRAL01"
       CONNECTION_PRINCIPAL_NAME="BA.CENTRAL01"
       SECURITY=DM_PW
   .
   .
   .
*DM_REMOTE
# <remote domain access point name> <domain type> <domain id> 
# [<connection principal name>]...
b01    TYPE=TDOMAIN
       ACCESSPOINTID="BA.BANK01"
       CONNECTION_PRINCIPAL_NAME="BA.BANK01"
関連項目

•

2-10ページの「プリンシパル名の指定」

•

2-15ページの「相互運用性のポリシーの指定」

•

で2-29ページの「ACLポリシーの設定」

•

2-4ページの「セキュリティ管理のタスク」

•

『Oracle Tuxedo Domainsコンポーネントの使用』の「ドメイン構成のセキュリティの設定」

ACLポリシーの設定

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

パラメータ名

説明

設定

DMCONFIGのACL_POLICY (DM_MIBのTA_DMACLPOLICY)

リモート・ドメイン・アクセス・ポイントごとに、DMCONFIGファイルのDM_REMOTEセクションで指定される場合があります。特定のリモート・ドメイン・アクセス・ポイントに対するこのパラメータの値により、ローカル・ドメイン・ゲートウェイがリモート・ドメインから受信したサービス・リクエストの資格(ID)を変更するかどうかが決まります。

LOCALまたはGLOBAL。デフォルトはLOCALです。

LOCALは、リモート・ドメインから受信したサービス・リクエストの資格証明を置き換えることを示します。GLOBALは、サービス・リクエストを変更せずに渡すことを示します。

DMCONFIGのLOCAL_PRINCIPAL_NAME (DM_MIBのTA_DMLOCALPRINCIPALNAME)

リモート・ドメイン・アクセス・ポイントごとに、DMCONFIGファイルのDM_REMOTEセクションで指定される場合があります。特定のリモート・ドメイン・アクセス・ポイントに対し、ACL_POLICYパラメータにLOCAL (デフォルト値)が設定された場合、ローカル・ドメイン・ゲートウェイは、リモート・ドメインから受け取ったサービス・リクエストの資格証明を、LOCAL_PRINCIPAL_NAMEパラメータで指定されているプリンシパル名に置き換えます。

1から511文字。指定しない場合、リモート・ドメイン・アクセス・ポイントのACCESSPOINTID文字列がデフォルト値になります。

次の3つの図は、ACL_POLICY構成が、ローカル・ドメイン・ゲートウェイ(GWTDOMAIN)のプロセスの動作に与える影響を示します。

図2-10 ローカルなACLポリシーの確立

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

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

注意:

以上の説明は、Oracle Tuxedoリリース7.1より前のソフトウェアを実行するATMIアプリケーションにも適用されます。ただし、システムでは、リモート・ドメイン・アクセス・ポイントに構成されたACCESSPOINTIDのIDが使用されます。基本的に、Oracle Tuxedoリリース6.5以前のソフトウェアでは、ローカルのACLポリシーはハードコーディングされています。

図2-11 グローバルなACLポリシーの確立

上の図では、各ドメイン・ゲートウェイ(GWTDOMAIN)は、インバウンドとアウトバウンドのクライアント・リクエストを変更しないで渡します。この構成では、各ATMIアプリケーションにACLデータベースがあります。このデータベースには、ドメイン内のユーザーに関するエントリのほか、リモート・ドメインのユーザーの情報も格納されます。

図2-12 一方向ローカルおよび一方向グローバルのACLポリシーの確立

上の図では、ATMIアプリケーション1のドメイン・ゲートウェイ(GWTDOMAIN)が、インバウンドのクライアント・リクエストを変更しています。変更されたリクエストは、ATMIアプリケーション2のリモート・ドメイン・アクセス・ポイントに構成されたLOCAL_PRINCIPAL_NAME IDを持つため、そのIDに設定されたアクセス権も取得することになります。アウトバウンドのクライアント・リクエストは、変更されずに渡されます。ATMIアプリケーション2のドメイン・ゲートウェイ(GWTDOMAIN)は、インバウンドとアウトバウンドのクライアント・リクエストを変更しないで渡します。

この構成のATMIアプリケーション1のACLデータベースには、ドメイン内のユーザーに関するエントリだけが含まれています。たとえば、アプリケーション2のリモート・ドメイン・アクセス・ポイントに設定されたLOCAL_PRINCIPAL_NAMEのIDを持つユーザーです。ATMIアプリケーション2のACLデータベースには、ドメイン内のユーザーに関するエントリのほか、ATMIアプリケーション1のユーザーのエントリも格納されています。

リモート・ドメイン・ゲートウェイの偽装化

ドメイン・ゲートウェイは、ローカルのDMCONFIGファイルのACL_POLICYパラメータにLOCAL (デフォルト)が設定されたリモート・ドメインからクライアント・リクエストを受け取ると、次のタスクを実行します。

1.

内部のユーザー偽装関数を呼び出して、リモート・ドメイン・アクセス・ポイントに構成されたLOCAL_PRINCIPAL_NAMEのIDに基づき、クライアントの認可トークンと監査トークンを取得します。

2.

取得したトークンを使用して、すでにクライアント・リクエストに添付されているトークンを上書きします。

3.

リクエストを送信先のサーバーに転送します。

ユーザー偽装関数の詳細は、2-19ページの「古いクライアントの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"
関連項目

•

2-10ページの「プリンシパル名の指定」

•

2-15ページの「相互運用性のポリシーの指定」

•

2-24ページの「ドメイン間のリンクの確立」

•

2-4ページの「セキュリティ管理のタスク」

資格証明ポリシーの設定

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

パラメータ名

説明

設定

DMCONFIGのCREDENTIAL_POLICY (DM_MIBのTA_DMCREDENTIALPOLICY)

リモート・ドメイン・アクセス・ポイントごとに、DMCONFIGファイルのDM_REMOTEセクションで指定される場合があります。特定のリモート・ドメイン・アクセス・ポイントに対するこのパラメータの値により、ローカル・ドメイン・ゲートウェイがこのリモート・ドメイン・アクセス・ポイントに送信するサービス・リクエストから資格(ID)を削除するかどうかが決まります。

CREDENTIAL_POLICYパラメータにより、ローカル・ドメイン・ゲートウェイがリモート・ドメインにローカル・サービス・リクエストを送信する前にそのリクエストから資格証明を削除するかどうかが決まります。ACL_POLICYパラメータにより、ローカル・ドメイン・ゲートウェイがリモート・ドメインから受信したサービス・リクエストの資格証明をLOCAL_PRINCIPAL_NAMEパラメータで指定されているプリンシパル名に置き換えるかどうかが決まります。

LOCALまたはGLOBAL。デフォルトはLOCALです。

LOCALに設定すると、このリモート・ドメイン・アクセス・ポイントに送信されるローカル・サービス・リクエストから資格証明が削除され、GLOBALに設定すると、このリモート・ドメイン・アクセス・ポイントに送信されるローカル・サービス・リクエストから資格証明が削除されません。

認可の管理

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

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

関連項目

•

1-12ページの「認可」

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

•

1-58ページの「セキュリティの互換性」

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

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

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

•

ワークステーション・クライアントからワークステーション・ハンドラ(WSH)へのリンク

•

ブリッジ間のリンク

•

管理ユーティリティ(tmbootなど)またはtlistenとのリンク

•

ドメイン・ゲートウェイ間のリンク

LLEのmin値とmax値の理解

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

•

minの場合: 0

•

maxの場合:インストール済のLLEバージョンで可能な暗号化の最高レベルを示すビット数

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

詳細は、1-22ページの「LLEのしくみ」および1-23ページの「暗号化キー・サイズのネゴシエーション」を参照してください。

ワークステーション・クライアントのリンクにLLEを構成する方法

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

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

注意:

ネットワーク接続の端にあるワークステーション・クライアントでは、TMMINENCRYPTBITSおよびTMMAXENCRYPTBITSの2つの環境変数を使用して、LLEのminおよびmaxパラメータのデフォルト値をオーバーライドできます。

ワークステーション・クライアントのリンクにLLEを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタでUBBCONFIGを開き、SERVERSセクションに次の行を追加します。

*SERVERS
WSL    SRVGRP="group_name" SRVID=server_number ...
       CLOPT="-A -- -z min -Z max ..."

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

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

詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のWSL(5)、WS_MIB(5)およびUBBCONFIG(5)に関する項を参照してください。

ブリッジ間のリンクにLLEを構成する方法

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

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

ブリッジ間のリンクにLLEを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタでUBBCONFIGを開き、NETWORKセクションに次の行を追加します。

*NETWORK
LMID   NADDR="bridge_network_address" BRIDGE="bridge_device"
       NLSADDR="listen_network_address"
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max

LMIDは、ブリッジ・サーバーが置かれた論理マシンであり、BRIDGEパラメータで指定されたネットワーク・デバイスに直接アクセスできます。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

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

詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のTM_MIB(5)およびUBBCONFIG(5)に関する項を参照してください。

tlistenのリンクにLLEを構成する方法

tlisten(1)は、ネットワークに依存しないリスナー・プロセスであり、tmboot(1)などの管理ユーティリティを実行できるマルチ・マシン・アプリケーションのノード間の接続を確立します。アプリケーション管理者は、UBBCONFIGファイルのNETWORKセクションで定義されたすべてのマシンにtlistenをインストールします。

tlistenリンクにLLEを構成するには、2-37ページの「ブリッジ間のリンクにLLEを構成する方法」で説明した手順に従います。必要に応じ、次のコマンドを入力して、ローカル・マシンで別個のtlistenのインスタンスを起動できます。

tlisten -l nlsaddr [-z min -Z max]

nlsaddr値は、UBBCONFIGファイルのNETWORKセクションでこのマシンのNLSADDRパラメータに指定した値と同じにする必要があります。詳細は、『Oracle Tuxedoコマンド・リファレンス』のtlisten(1)に関する項、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のTM_MIB(5)およびUBBCONFIG(5)に関する項を参照してください。

ドメイン・ゲートウェイのリンクにLLEを構成する方法

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

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

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

•

リモート・ドメイン・アクセス・ポイントからローカル・サービスに対するリクエストを受け付けるローカル・ドメイン・アクセス・ポイント

•

定義されたローカル・ドメイン・アクセス・ポイントがアクセスできるリモート・ドメイン・アクセス・ポイント

•

特定のローカル・ドメイン・アクセス・ポイントとリモート・ドメイン・アクセス・ポイント間のTDomainセッション

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

ドメイン・ゲートウェイのリンクにLLEを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタでDMCONFIGを開き、DM_TDOMAINセクションに次の行を追加します。

*DM_TDOMAIN
# Local network addresses
LDOM   NWADDR="local_domain_network_address"
       NWDEVICE="local_domain_device"
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max
       .
       .
       .

# Remote network addresses
RDOM   NWADDR="remote_domain_network_address"
       NWDEVICE="remote_domain_device"
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max
       .
       .
       .

# TDomain network addresses
RDOM   NWADDR="remote_domain_network_address"
       NWDEVICE="remote_domain_device"
       CONNECTION_POLICY=ON_START
       LACCESSPOINT="local_domain_access_point_identifier"
       FAILOVERSEQ=100
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max

LDOMはローカル・ドメインのアクセス・ポイントIDで置き換えられ、RDOMはリモート・ドメインのアクセス・ポイントIDで置き換えられます。

3.

dmloadcf(1)を実行して構成をロードします。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。

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

詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG(5)に関する項を参照してください。また、『Oracle Tuxedo Domainsコンポーネントの使用』のドメイン構成のセキュリティの設定に関する項も参照してください。

関連項目

•

1-22ページの「リンク・レベルの暗号化」

•

2-4ページの「セキュリティ管理のタスク」

•

1-53ページの「セキュリティの相互運用性」

•

1-58ページの「セキュリティの互換性」

SSL暗号化の管理

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

SSLのmin値とmax値の理解

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

•

minの場合: 0

•

maxの場合:インストール済のSSLバージョンで可能な暗号化の最高レベルを示すビット数

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

ワークステーション・クライアントのリンクにSSLを構成する方法

ワークステーション・クライアントのリンクにSSLを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.

SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARパラメータを指定する必要があります。これらのパラメータは、*RESOURCES、*MACHINES、*GROUPS、または*SERVERSセクションで指定できます。

注意:

通常、これらのパラメータにはできるかぎり大きな値を指定することをお薦めします。これは、UBBCONFIG内での情報の重複を避け、tmloadcfを対話的に実行した場合に複数のパスワード・プロンプトが表示されることを防ぐためです。

3.

テキスト・エディタでUBBCONFIGを開き、SERVERSセクションに次の行を追加します。

*SERVERS
WSL    SRVGRP="group_name" SRVID=server_number ...
       CLOPT="-A -- -z min -Z max -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環境変数は、ウォレットを開くために使用されます。

注意:

•

SEC_PRINCIPAL_NAMEを設定しないことも可能です。この場合、0長の文字列とみなされます。

•

一方向SSLの従来のセキュリティ資格証明は実行時にOracle Walletに変換され、SEC_PRINCIPAL_PASSWORD環境変数が作成時に設定されない場合は、デフォルト・パスワードTrustedCertsOnlyNoPWNeededがウォレットを作成するために使用されます。そのようなウォレットは、SEC_PRINCIPAL_PASSWORD環境変数を設定せずに後でアクセスできます。

WSL -a (相互認証)オプションが使用されている場合、WSCは自らの証明書と秘密鍵の場所も指定する必要があります。従来のセキュリティ資格証明とOracle Walletのどちらが使用されるかにかかわらず、これらの資格証明にアクセスするにはSEC_PRINCIPAL_LOCATION、SEC_PRINCIPAL_NAMEおよびSEC_PRINCIPAL_PASSWORD環境変数を設定する必要があります。

4.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

ブリッジ間のリンクにSSLを構成する方法

ブリッジ間のリンクにSSLを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタで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パラメータで指定されたネットワーク・デバイスに直接アクセスできます。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

tlistenのリンクにSSLを構成する方法

tlistenリンクにSSLを構成するには、2-37ページの「ブリッジ間のリンクにLLEを構成する方法」で説明した手順に従います。次のコマンドを入力する必要があります。

tlisten -l nlsaddr [-z min -Z max][-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を構成する方法

ドメイン・ゲートウェイのリンクにSSLを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

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 addresses
RDOM   NWADDR="remote_domain_network_address"
       NWDEVICE="remote_domain_device"
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max
       .
       .
       .

# TDomain network addresses
RDOM   NWADDR="remote_domain_network_address"
       NWDEVICE="remote_domain_device"
       CONNECTION_POLICY=ON_START
       LACCESSPOINT="local_domain_access_point_identifier"
       FAILOVERSEQ=100
       MINENCRYPTBITS=min
       MAXENCRYPTBITS=max

LDOMはローカル・ドメインのアクセス・ポイントIDで置き換えられ、RDOMはリモート・ドメインのアクセス・ポイントIDで置き換えられます。

3.

UBBCONFIGファイルで、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSWORDを指定する必要があります。

4.

dmloadcf(1)を実行して構成をロードします。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。

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

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

管理手順の詳細は、『CORBAアプリケーションにおけるセキュリティの使用』の公開鍵によるセキュリティ機能の管理に関する項およびSSLプロトコルの構成に関する項を参照してください。

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

注意:

Oracle CORBA C++ ORBをサーバー・アプリケーションとして使用している場合、ORBでもSSLプロトコルを使用するように構成できます。詳細は、『CORBAアプリケーションにおけるセキュリティの使用』のSSLプロトコルの構成に関する項を参照してください。

表2-2 SSLプロトコル用の管理手順

手順

説明

1

LDAP対応ディレクトリ・サービスを構成します。Oracle Tuxedo製品のインストール時に、LDAPサーバーの名前を入力する必要があります。

2

SSLプロトコルを使用するためのライセンスをインストールします。

3

Oracle Tuxedoアプリケーションのデジタル証明書および秘密鍵を認証局から取得します。

4

Oracle Tuxedoアプリケーションと認証局のデジタル証明書をLDAP対応ディレクトリ・サービスで公開します。

5

Tuxedoサーバー・プロセスのSEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARパラメータをUBBCONFIGファイルで定義します。

6

UBBCONFIGパラメータ、DMCONFIGパラメータ、WSL CLOPT、JSL CLOPT、またはISL CLOPTの設定を変更してSSLをオンにします。

7

適切な構成ファイルまたはサーバーCLOPTで、SSL通信用のポートを定義します。

8

Oracle Tuxedoアプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル(trust_ca.cer)を作成します。

9

tmloadcfコマンドやdmloadcfコマンドを使用して適切な構成ファイルがロードされるように変更します。

10

オプションで、Oracle Tuxedo製品のピア規則ファイル(peer_val.rul)を作成します。

11

オプションで、社内のディレクトリ階層に合せてLDAP検索フィルタ・ファイルを変更します。

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

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

図2-13 TuxedoアプリケーションでSSLプロトコルを使用する構成

Oracle Walletの作成

Oracle Walletは次のいずれかの方法で作成できます。

•

owmグラフィカル・ツールの使用(Oracle Databaseをインストールしているユーザー向け)

•

orapkiコマンド行ツールの使用(Oracle Databaseをインストールしているユーザー向け)

•

opensslまたは他のサード・パーティ・ツールの使用

•

実行時に自動作成(Tuxedo 11g以前のリリースで使用されるセキュリティ資格証明が変換される)

orapkiを使用したOracle Walletの作成

orapkiを使用したOracle Walletの作成方法の詳細は、『Oracle Database Advanced Security管理者ガイド』のorapkiユーティリティに関する項を参照してください。

Oracle Tuxedoのウォレットにはパスワードが必要なため、「自動ログイン」オプションは使用できません。orapkiおよびowmを使用して新しい秘密鍵と証明書を持つウォレットを生成することはできますが、これらのツールの現行バージョンでは、以前使用されていた秘密鍵と証明書をウォレットにインポートできません。既存の秘密鍵と証明書のペアをウォレットにインポートする必要がある場合は、実行時変換、openssl、または別のサード・パーティ・ツールを使用してください。

opensslを使用したOracle Walletの作成

次に、Oracle Walletの作成に使用できるopensslコマンドの例を示します。

リスト2-1 opensslを使用したOracle Walletの作成の例
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: 新しく作成したウォレットのパスワードを指定します。

注意:

•

opensslの実行時に他のユーザーが"ps"を実行する可能性がある場合は、-passinおよび-passoutパラメータを省略して、opensslでパスワードを要求する必要があります。

•

opensslでOracle Walletを作成する場合、Oracle Walletではウォレット・パスワードと秘密鍵パスワードは区別されないため、"-passin"パラメータは"-passout"パラメータと同じ値である必要があります。

実行時のOracle Walletの作成

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ウォレット・ファイルは、プロセスの秘密鍵(ある場合)とユーザー証明書(ある場合)だけでなく、チェーンの他の証明書および信頼性のある証明書も使用して作成されます。

Oracleウォレットの実行時作成中、新しく作成されるウォレットの場所の指定にSEC_PRINCIPAL_LOCATIONが使用されます。それは、サーバーまたはクライアントいずれかの独自の秘密鍵として定義する必要があります。

たとえば、秘密鍵ファイルISH_tuxqa.pemが/home/tuxedo/myappにある場合は、SEC_PRINCIPAL_LOCATION="/home/tuxedo/myapp/ISH_tuxqa.pem"と定義します。このようにして、ウォレットが/home/tuxedo/myapp/wallet.ISH_tuxqa.pem/ewallet.p12に作成されます。

注意:

「Oracle Walletの作成」で説明した方法で手動でウォレットを作成する場合は、前述のルールに従って適切なディレクトリにウォレットを作成する必要があります。そうでない場合、ウォレットが検索できません。

例外的に、手動でウォレットを作成する場合、SEC_PRINCIPAL_LOCATIONを秘密鍵ファイルとして定義する以外に、ディレクトリとして定義できます。この方法では、SEC_PRICIPAL_LOCATIONおよびSEC_PRINCIPAL_NAMEの両方がウォレットの検索に使用されます。

たとえば、SEC_PRINCIPAL_LOCATION="/home/tuxedo/myapp"およびSEC_PRINCIPAL_NAME="ISH_tuxqa"と定義している場合、手動で作成したウォレットを/home/tuxedo/myapp/wallet.ISH_tuxqa/ewallet.p12にコピーする必要があります。そうしないと、それが見つかりません。

TUXCREATEWALLET環境変数の使用

従来のセキュリティ資格証明の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オプションは効率が低下しますが、次の場合に必要です。

•

プラグイン・フレームワークから取得される従来形式のセキュリティ資格証明が、動的に変更する可能性がある場合。

•

セキュリティなどの理由のために、アプリケーションのウォレットをローカル・ファイル・システムに格納することが望ましくない場合。

•

SEC_PRINCIPAL_LOCATIONが読取り専用ファイル・システムにある場合。

•

TUXCREATEWALLET=NOまたはTUXCREATEWALLET=anyothervalue: ウォレットが存在しない場合、エラーが報告されます。従来形式のセキュリティ資格証明は使用されません。

KEEPまたはTEMPの値は、大文字と小文字の区別はありませんが、これらの4文字で指定する必要があります。YESまたはNOの値は、Tuxedoの他の多くのYes/No環境変数と同じく、ローカル言語で指定することもできます。

SSL接続の問題のデバッグ

NZトレース機能の有効化

環境変数TUXNZTRACE=8191が設定されると、TuxedoはプロセスのSSLトレースをtrace-process_id.logという名前のファイルに出力します。トレース出力には、SSLハンドシェイク・プロセスで送信される情報と、暗号化されたアプリケーション・データが含まれます。このトレースは、特定の証明書チェーンが有効とみなされない理由や、SSLハンドシェイク・プロセスに他のエラーがある理由を判別するときに特に役立ちます。

接続確立のログ・メッセージ

環境変数ULOG_SSLINFO=yesが設定されると、SSL接続が確立されるたびにTuxedoがメッセージをユーザー・ログに書き込みます。これには、ネゴシエーションされた暗号の名前が含まれます。

Oracle Walletの内容の表示

様々なツールを使用して、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
NZエラー・コード情報の取得

多くのSSLエラー・メッセージには、Oracle NZセキュリティ・レイヤーから返されるエラー・コード番号が含まれます。一部のエラー・メッセージでは、その後にNZエラー番号の短い説明文が続きます。NZエラー・コードの説明文が含まれないエラー・メッセージの場合、この情報はファイル$TUXDIR/locale/C/ORACLE.textを検索して取得できます。

Oracle Databaseソフトウェアをインストールしているユーザーは、特定のエラー番号に関連する文字列を判別するためにoerrコマンドを使用することもできます。

関連項目

•

1-26ページの「SSL暗号化」

•

2-4ページの「セキュリティ管理のタスク」

•

UBBCONFIG(5)のRESOURCESセクション

•

DM_MIB(5) T_DM_TDOMAINクラス

•

DMCONFIG(5) DM_TDOMAINセクション

•

WS_MIB(5) T_WSLクラス

•

CORBAアプリケーションにおけるセキュリティの使用

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

分散型のATMIアプリケーションの安全性を確保する最も効果的な方法は、リンク・レベルの暗号化と公開鍵による暗号化を組み合せることです。公開鍵による暗号化は、公開鍵セキュリティの基盤となるフレームワークです。

公開鍵セキュリティにより、メッセージ・ベースのデジタル署名とメッセージ・ベースの暗号化をATMIアプリケーションに統合することができます。これらの機能を組み合せると、データの整合性と機密性が保たれます。これは、ATMIアプリケーションが外部のATMIアプリケーションまたはワークステーション・クライアントと相互運用する場合に特に重要です。

公開鍵セキュリティで推奨されている事項について

•

実行できるセキュリティのレベルは、主にATMIアプリケーションの動作環境によって決まります。最も高いセキュリティのレベルを実現するには、秘密鍵の情報を保護するハードウェア・デバイスをインストールします。

•

鍵の有効期限と鍵の更新手順についてのポリシーを決定します。認証局が発行する証明書の有効期限は、システムの操作に大きく影響する場合があります。したがって、有効期限の前に、更新した証明書を発行できるようにしておく必要があります。

公開鍵と秘密鍵の組合せの割当て

アプリケーションの管理者と開発者は、公開鍵と秘密鍵の組合せ、および関連するデジタル証明書を認証するための認証局を選択する必要があります。次に、鍵の組合せをATMIアプリケーションに割り当てる方法を決定する必要があります。鍵の組合せを割り当てる方法はたくさんあります。管理者は、次のうち、1つまたは複数の方法で鍵の組合せを割り当てることができます。

•

1つの公開鍵をATMIアプリケーション全体に割り当てる

•

ATMIアプリケーション内の各マシンに対して公開鍵と秘密鍵の組合せを1つ割り当てる

•

ATMIアプリケーション内の各サーバーに対して公開鍵と秘密鍵の組合せを1つ割り当てる

•

ATMIアプリケーション内の各サービスに対して公開鍵と秘密鍵の組合せを1つ割り当てる

•

各エンド・ユーザーに対して公開鍵と秘密鍵の組合せを1つ割り当てる

アプリケーションの管理者と開発者は、鍵の組合せを割り当てる方法を選択し、実際に割り当てる責任があります。ただし、鍵の組み合わせを割り当てた後の管理作業を行う必要はありません。鍵の配布と管理は、公開鍵セキュリティのプラグインによって行われます。

デジタル署名ポリシーの設定

管理者は、次の構成パラメータを使用して、ATMIアプリケーションのデジタル署名に関するポリシーを設定します。

パラメータ名

説明

設定

UBBCONFIGのSIGNATURE_AHEAD (TM_MIBのTA_SIGNATURE_AHEAD)

デジタル署名付きのメッセージ・バッファに記録されたタイムスタンプ値と、そのメッセージ・バッファが受信された時刻の最大時間差。デジタル署名のタイムスタンプ値が遠い将来の時刻を示す場合、受信側のプロセスではメッセージ・バッファを拒否します。

1-2147483647秒。デフォルト値は3600秒(1時間)です。

UBBCONFIGのSIGNATURE_BEHIND (TM_MIBのTA_SIGNATURE_BEHIND)

デジタル署名付きのメッセージ・バッファが受信された時刻と、そのメッセージ・バッファに添付されたタイムスタンプ値との最大時間差。デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、受信側のプロセスではメッセージ・バッファを拒否します。

1-2147483647秒。デフォルト値は604800秒(1週間)です。

UBBCONFIGのSIGNATURE_REQUIRED (TM_MIBのTA_SIGNATURE_REQUIRED)

受信側のプロセスで受け付けるメッセージ・バッファを、デジタル署名付きのものだけに制限するかどうかを決定します。

Y (yes - デジタル署名が必要)またはN (no - デジタル署名は不要)を指定します。デフォルトはNです。

デジタル署名のタイムスタンプに設定された将来の日付を制限する

SIGNATURE_AHEADは、構成階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMIアプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIGファイルのRESOURCESセクションおよびTM_MIBのT_DOMAINクラスで設定されます。

SIGNATURE_AHEADパラメータは、(1)受信メッセージ・バッファに添付されたタイムスタンプと、(2)検証システムのローカル・クロックに表示される現在時刻との最大許容時間差を設定します。最小値は1秒です。最大値は2147483647秒です。デフォルトは3600秒(1時間)です。

デジタル署名のタイムスタンプが遠い将来の時刻を示す場合、その署名は無効と見なされます。このパラメータは、同期されていないローカル・クロックとの間の許容時間差を受け入れつつ、将来の日付が設定された署名を拒否するのに便利です。

将来の日付を制限するUBBCONFIGのエントリ例
*RESOURCES
SIGNATURE_AHEAD 2400
デジタル署名のタイムスタンプに設定された過去の日付を制限する

SIGNATURE_BEHINDは、構成階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMIアプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIGファイルのRESOURCESセクションおよびTM_MIBのT_DOMAINクラスで設定されます。

SIGNATURE_BEHINDパラメータは、(1)検証システムのローカル・クロックに表示される現在時刻と、(2)受信メッセージ・バッファに添付されたタイムスタンプとの最大許容時間差を設定します。最小値は1秒です。最大値は2147483647秒です。デフォルトは604800秒(1週間)です。

デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、その署名は無効とみなされます。このパラメータを設定すると、リプレイ攻撃、つまり、署名付きの有効なバッファが再びシステムに送信されるのを阻止することができます。ただし、非同期通信を行うシステム、たとえばディスク・ベースのキューを使用するシステムでは、かなり古い署名が添付されたバッファが有効とみなされる場合があります。したがって、非同期通信を行うシステムでは、SIGNATURE_BEHINDの設定を増やしてください。

過去の日付を制限するUBBCONFIGのエントリ例
*RESOURCES
SIGNATURE_BEHIND 300000
受信メッセージに対する署名ポリシーの適用

SIGNATURE_REQUIREDは、構成の階層のうち、次の4つのレベルのどこでも指定できます。

•

UBBCONFIGファイルのRESOURCESセクション、またはTM_MIBのT_DOMAINクラス

•

UBBCONFIGファイルのMACHINESセクション、またはTM_MIBのT_MACHINEクラス

•

UBBCONFIGファイルのGROUPSセクション、またはTM_MIBのT_GROUPクラス

•

UBBCONFIGファイルのSERVICESセクション、またはTM_MIBのT_SERVICEクラス

特定のレベルで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の詳細は、2-58ページの「受信メッセージに対する暗号化ポリシーの適用」を参照してください。

修飾子

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

例

mach1というマシンにSIGNATURE_REQUIREDを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタで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

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

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

•

userlog(3c)メッセージを生成します(重大度はWARN (警告))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

注意:

NULLバッファ(空のバッファ)にデジタル署名を添付することはできません。したがって、デジタル署名を必要とするプロセスで受信されたNULLバッファは、前述のいずれかの方法で、システム側で拒否されます。

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

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

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

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

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

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

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

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

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

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

暗号化ポリシーの設定

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

パラメータ名

説明

設定

UBBCONFIGのENCRYPTION_REQUIRED (TM_MIBのTA_ENCRYPTION_REQUIRED)

受信側のプロセスで受け付けるメッセージ・バッファを、暗号化されたものだけに制限するかどうかを決定します。

Y (yes - 暗号化が必要)またはN (no - 暗号化は不要)を指定します。デフォルトはNです。

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

ENCRYPTION_REQUIREDは、構成の階層のうち、次の4つのレベルのどこでも指定できます。

•

UBBCONFIGファイルのRESOURCESセクション、またはTM_MIBのT_DOMAINクラス

•

UBBCONFIGファイルのMACHINESセクション、またはTM_MIBのT_MACHINEクラス

•

UBBCONFIGファイルのGROUPSセクション、またはTM_MIBのT_GROUPクラス

•

UBBCONFIGファイルのSERVICESセクション、またはTM_MIBのT_SERVICEクラス

特定のレベルで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の詳細は、2-55ページの「受信メッセージに対する署名ポリシーの適用」を参照してください。

修飾子

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

例

STDGRPというサーバー・グループにENCRYPTION_REQUIREDを構成するには、次の手順に従います。

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタでUBBCONFIGを開き、GROUPSセクションに次の行を追加します。

*GROUPS
STDGRP LMID="machine_logical_name"
       GRPNO="server_group_number"
       ENCRYPTION_REQUIRED=Y

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

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

•

userlog(3c)メッセージを生成します(重大度はERROR (エラー))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

注意:

NULLバッファ(空のバッファ)は暗号化できません。したがって、暗号化を必要とするプロセスで受信されたNULLバッファは、前述のいずれかの方法で、システム側で拒否されます。

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

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

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

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

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

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

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

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

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

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

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

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

パラメータ名

説明

設定

UBBCONFIGのSEC_PRINCIPAL_NAME (TM_MIBのTA_SEC_PRINCIPAL_NAME)

ターゲットのプリンシパル名。これが1つまたは複数のシステム・プロセスのIDになります。

1から511文字。

UBBCONFIGのSEC_PRINCIPAL_LOCATION (TM_MIBのTA_SEC_PRINCIPAL_LOCATION)

ターゲットのプリンシパルの復号化(プライベート)キーが格納されているファイルまたはデバイスの位置。

0から1023文字。指定しない場合、NULL文字列(長さゼロ)がデフォルト値になります。

UBBCONFIGのSEC_PRINCIPAL_PASSVAR (TM_MIBのSEC_PRINCIPAL_PASSVAR)

ターゲットのプリンシパルのパスワードが格納されている変数。

0から31文字。指定しない場合、NULL文字列(長さゼロ)がデフォルト値になります。

前述の3つのパラメータは、構成の階層のうち、次の4つのレベルのどこでも指定できます。

•

UBBCONFIGファイルのRESOURCESセクション、またはTM_MIBのT_DOMAINクラス

•

UBBCONFIGファイルのMACHINESセクション、またはTM_MIBのT_MACHINEクラス

•

UBBCONFIGファイルのGROUPSセクション、またはTM_MIBのT_GROUPクラス

•

UBBCONFIGファイルのSERVERSセクション、またはTM_MIBのT_SERVERクラス

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

•

serv1プロセス以外のmach1上のすべてのプロセスは、mach1に割り当てられた復号化キーを使用して、暗号化された受信メッセージ・バッファを復号化します。

•

serv1上のすべてのプロセスは、serv1に割り当てられた復号化キーを使用して、暗号化された受信メッセージ・バッファを復号化します。

ATMIアプリケーションが起動すると、構成された復号化キーは自動的にオープンします。図2-14は、このプロセスのしくみを示しています。

図2-14 復号化キーの初期化例

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

1.

管理者は、ATMIアプリケーションのUBBCONFIGファイルの特定のレベルで、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARを定義します。

2.

管理者は、tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

3.

管理者は、プロンプトに従い、ターゲットのプリンシパルのパスワードを入力し、さらにもう一度入力します。

4.

管理者は、tmboot(1)コマンドを実行してATMIアプリケーションを起動します。

5.

起動時に、map_proofプラグインにより、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARが読み込まれ、各パラメータの値が解析されます。次に、呼出しプロセスで、リクエストされた復号化キーに対するアクセス権が証明されたかどうかが判別されます。復号化キー、つまり秘密鍵にアクセスできるということは、プリンシパルのIDを所有することと同じです。

6.

SEC_PRINCIPAL_PASSVARに関連するパスワードが、SEC_PRINCIPAL_NAMEで指定されたプリンシパルに割り当てられたパスワードと一致する場合、map_proofプラグインは、プリンシパルの名前、位置、およびパスワードをPKi_initプラグインに渡します。

7.

PKi_initプラグインは、プリンシパルの名前、位置、およびパスワードを引数に指定し、tpkey_open(3c)を呼び出します。プリンシパルの復号化キー・ハンドルが返されます。

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の場合(3-53ページの「コンポジット署名ステータスの理解」を参照)、システム側では次のアクションが実行されます。

•

userlog(3c)メッセージを生成します(重大度はERROR (エラー))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

有効期限が切れた証明書、取り消された証明書、有効期限が切れた署名、または古い日付の署名が検出された場合、システム側では次のアクションが実行されます。

•

userlog()メッセージを生成します(重大度はWARN (警告))。

•

バッファのコンポジット署名ステータスがTPSIGN_OKまたはTPSIGN_UNKNOWNでないかぎり、バッファを破棄し、プロセスで受信されなかったように扱います。

SIGNATURE_REQUIRED=Yの設定に基づいて有効なデジタル署名を必要とするプロセスが、コンポジット署名ステータスTPSIGN_UNKNOWNが添付されたメッセージを受信した場合、システム側では次のアクションが実行されます。

•

userlog()メッセージを生成します(重大度はWARN (警告))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

暗号化のエラー処理

プロセスが、メッセージの暗号化エンベロープのいずれかと一致するオープンした復号化キーを持たない状態で、暗号化されたメッセージを受信した場合、システムは次のアクションを実行します。

•

userlog(3c)メッセージを生成します(重大度はERROR (エラー))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

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

•

userlog()メッセージを生成します(重大度はERROR (エラー))。

•

バッファを破棄し、プロセスで受信されなかったように扱います。

関連項目

•

1-32ページの「公開鍵によるセキュリティ機能」

•

1-42ページの「公開鍵の実装」

•

2-4ページの「セキュリティ管理のタスク」

•

1-53ページの「セキュリティの相互運用性」

•

1-58ページの「セキュリティの互換性」

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

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

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

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

管理者は、UBBCONFIG構成ファイルを編集するか、またはTM_MIBを変更することにより、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 TuxedoサーバーであるAUTHSVRは、認証を実行する1つのサービス(AUTHSVC)を備えています。セキュリティ・レベルがACLまたはMANDATORY_ACLに設定されている場合、AUTHSVRサーバーは、AUTHSVCを..AUTHSVCとして通知します。

AUTHSVCをATMIアプリケーションに追加するには、UBBCONFIGファイルで、認証サービスとしてAUTHSVCを定義し、認証サーバーとしてAUTHSVRを定義する必要があります。例:
*RESOURCES
SECURITY   USER_AUTH
AUTHSVC    AUTHSVC
   .
   .
   .
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パラメータと値の組合せであるAUTHSVC AUTHSVCのエントリを省略すると、デフォルトでAUTHSVCが呼び出されます。

別の例を示します。
*RESOURCES
SECURITY   ACL
AUTHSVC    ..AUTHSVC
   .
   .
   .
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パラメータと値の組合せであるAUTHSVC ..AUTHSVCのエントリを省略すると、デフォルトで..AUTHSVCが呼び出されます。

AUTHSVRは、ATMIアプリケーション固有のロジックを実装する認証サーバーと置き換えることができます。たとえば、広く使用されているKerberosのメカニズムを使用して認証を行うため、認証サーバーをカスタマイズすることもできます。

カスタマイズした認証サービスをATMIアプリケーションに追加するには、UBBCONFIGファイルで認証サービスと認証サーバーを定義する必要があります。例:
*RESOURCES
SECURITY   USER_AUTH
AUTHSVC    KERBEROS
   .
   .
   .
*SERVERS
KERBEROSSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
注意:

•

Tuxedoユーザーを認証するためのセキュリティ・データベースとしてWebLogic Serverを使用するには、認証サーバーとしてLAUTHSVRを使用して、シングル・ポイント・セキュリティ管理を実装する必要があります。WebLogic ServerとLAUTHSVRおよびシングル・ポイント・セキュリティ管理については、4-1ページの「シングル・ポイント・セキュリティ管理の実装」を参照してください。

•

Tuxedoユーザーを認証および認可するためのセキュリティ・データベースとしてLDAPリポジトリを使用するには、XAUTHSVRを認証および認可サーバーとして使用する拡張可能なセキュリティ管理を実装する必要があります。XAUTHSVRおよび拡張可能なセキュリティ管理の詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のXAUTHSVR(5)に関する項を参照してください。

関連項目

•

2-68ページの「アプリケーション・パスワードによるセキュリティを有効にする方法」

•

2-69ページの「ユーザー・レベルの認証によるセキュリティを有効にする方法」

•

2-73ページの「アクセス制御リストによるセキュリティの有効化」

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

•

4-1ページの「シングル・ポイント・セキュリティ管理の実装」

•

『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のAUTHSVR(5)に関する項

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

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

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

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

UBBCONFIGファイルのRESOURCESセクションのSECURITYパラメータにAPP_PWを構成します。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.

パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはATMIアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.

電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。

関連項目

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

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

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

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

1.

UBBCONFIGファイルを設定します。

2.

ユーザー・ファイルとグループ・ファイルを設定します。

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

UBBCONFIGファイルの設定

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタで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によってATMIアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンド行オプションのみをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.

パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはATMIアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.

電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。

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

デフォルトの認可システムで使用できる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のセキュリティ・レベルに対するユーザー識別子および関連するグループ識別子が含まれます。(アプリケーション・キーの詳細は、1-48ページの「アプリケーション・キー」を参照してください。)

次は、tpgrpファイル内のサンプル・エントリです。

管理者は、tpusrファイルおよびtpgrpファイルで、ユーザーとグループのリストを定義しなければなりません。これらのファイルは、ATMIアプリケーションのAPPDIR変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。

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

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

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

/etc/passwordファイルをOracle Tuxedoシステムで受け付けられる形式に変換するには、次のコマンドを入力します。

tpaclcvt-u/etc/password

このコマンドにより、tpusrファイルが作成され、変換されたデータが格納されます。tpusrファイルがすでに存在する場合、tpaclcvtにより、変換したデータがファイルに追加されます。ただし、重複するユーザー情報が追加されることはありません。

注意:

シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザーごとにパスワードの入力が要求されます。

3.

/etc/groupファイルをOracle Tuxedoシステムで受け付けられる形式に変換するには、次のコマンドを入力します。

tpaclcvt-g/etc/group

このコマンドにより、tpgrpファイルが作成され、変換されたデータが格納されます。tpgrpファイルがすでに存在する場合、tpaclcvtにより、変換したデータがファイルに追加されます。ただし、重複するグループ情報が追加されることはありません。

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

Oracle Tuxedoシステムでは、アプリケーション・ユーザーのリストをtpusrというファイルで管理し、グループのリストをtpgrpというファイルで管理する必要があります。これらのファイルのエントリを変更するには、コマンドを発行するか、またはACL_MIB内の適切な属性を変更します。

コマンドを使用してユーザーおよびグループのエントリを変更する

次のいずれかのコマンドを実行すると、tpusrファイルおよびtpgrpファイルのエントリをいつでも追加、変更、または削除できます。

実行

目的

エントリが格納されているファイル名

tpusradd(1)

追加

tpusr

tpusrmod(1)

変更

tpusrdel(1)

削除

tpgrpadd(1)

追加

tpgrp

tpgrpmod(1)

変更

tpgrpdel(1)

削除

これらのコマンドを実行するには、次の手順に従います。

1.

非アクティブなATMIアプリケーションの場合、アプリケーションのMASTERマシンで作業していることを確認します。アクティブなATMIアプリケーションの場合は、構成内のどのマシンからでも作業できます。

2.

コマンドの実行方法については、『Oracle Tuxedoコマンド・リファレンス』で各コマンドのエントリを参照してください。

ACL_MIBを使用してユーザーおよびグループのエントリを変更する

コマンド行インタフェース以外の方法として、ACL_MIB(5)のT_ACLPRINCIPALクラスの該当する属性値を変更して、tpusrのユーザー・エントリを追加、変更、または削除できます。tpusradd(1)では一度に1人のユーザーしか追加できないため、同時に複数のユーザー・エントリを追加する場合は、この方法の方がコマンド行インタフェースより効率的です。

同様に、ACL_MIB(5)のT_ACLGROUPクラスの該当する属性値を変更すると、tpgrpのグループ・エントリを追加、変更、または削除できます。tpgrpadd(1)では一度に1つのグループしか追加できないため、同時に複数のグループ・エントリを追加する場合は、この方法の方がコマンド行インタフェースより効率的です。

関連項目

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

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

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

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

•

システム管理を簡素化できます。新しいサービスへのアクセス権を付与する場合、1つのグループに対してアクセス権を付与する方が、個別の複数のユーザーに付与するより簡単です。

•

パフォーマンスを高めることができます。エンティティを呼び出すたびにアクセス・パーミッションをチェックする必要があるため、パーミッションはすばやく解決できなければなりません。グループの数はユーザーの数より少ないため、権限を持つユーザーのリストを検索するよりも、権限を持つグループのリストを検索する方が高速です。

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

•

tpusrにはユーザーのリストが格納されています。

•

tpgrpにはグループのリストが格納されています。

•

tpaclには、アクセス制御リスト(ACL)と呼ばれる、アプリケーション・エンティティ(サービスなど)に対するグループのマッピングのリストが格納されています。

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

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

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

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

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

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

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

1.

UBBCONFIGファイルを設定します。

2.

ACLファイルを設定します。

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

UBBCONFIGファイルの設定

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタで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によってATMIアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンド行オプションのみをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.

パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはATMIアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.

電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。

ACLファイルの設定

アクセス制御のチェック機能では、tpusrというユーザー・ファイル、tpgrpというグループ・ファイル、およびtpaclというACLファイルが必要です。ACLファイルには、グループとアプリケーション・エンティティのマッピングが含まれています。エンティティとは、サービス、イベント、またはアプリケーション・キューです。

次は、tpaclファイル内のサンプル・エントリです。

管理者はtpaclファイルでエントリを定義しなければなりません。tpaclファイルは、ATMIアプリケーションのAPPDIR変数で定義した最初のパス名によって参照されるディレクトリにあります。これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者だけが読み書きを行う権限を持ちます。

tpaclファイルのACLのエントリを変更するには、コマンドを発行するか、またはACL_MIB内の適切な属性を変更します。

コマンドを使用してACLエントリを変更する

次のいずれかのコマンドを実行すると、tpaclファイルのACLエントリをいつでも追加、変更、または削除できます。

実行

目的

tpacladd(1)

エントリの追加

tpaclmod(1)

エントリの変更

tpacldel(1)

エントリの削除

これらのコマンドを実行するには、次の手順に従います。

1.

非アクティブなATMIアプリケーションの場合、アプリケーションのMASTERマシンで作業していることを確認します。アクティブなATMIアプリケーションの場合は、構成内のどのマシンからでも作業できます。

2.

コマンドの実行方法については、『Oracle Tuxedoコマンド・リファレンス』で各コマンドのエントリを参照してください。

ACL_MIBを使用してACLエントリを変更する

コマンド行インタフェース以外の方法として、ACL_MIB(5)のT_ACLPERMクラスの該当する属性値を変更して、tpaclのACLエントリを追加、変更、または削除できます。tpacladd(1)では一度に1つのACLエントリしか追加できないため、同時に複数のACLエントリを追加する場合は、この方法の方がコマンド行インタフェースより効率的です。

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

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

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

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

1.

UBBCONFIGファイルを設定します。

2.

ACLファイルを設定します。

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

UBBCONFIGファイルの設定

1.

ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。

2.

テキスト・エディタで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によってATMIアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンド行オプションのみをAUTHSVRに渡します。デフォルトでは、AUTHSVRは、tpusrというファイル内のクライアント・ユーザー情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。tpusrは、ATMIアプリケーションのAPPDIR変数で定義する最初のパス名によって参照されるディレクトリにあります。

3.

tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.

パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはATMIアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.

電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。

ACLファイルの設定

2-75ページの「ACLファイルの設定」を参照してください。

関連項目

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

•

2-4ページの「セキュリティ管理のタスク」

一般的なLDAPベース・セキュリティを有効にする方法

一般的なLDAPベース・セキュリティには、ユーザー・レベルの認証とアクセス制御セキュリティが含まれます。

このセキュリティ・メカニズムにより、認証と認可は、TUXEDO "..ATNSVC"および"..ATZSVC"の管理サービスを呼び出すことで実行されます。これにより柔軟性が向上し、Oracle Tuxedoユーザーはセキュリティ情報を独立したリポジトリに格納して、それらのセキュリティ情報に"..ATNSVC"サービスと"..ATZSVC"サービスからアクセスできるようになります。Oracle Tuxedoでは、これら2つの管理サービスを通知するXAUTHSVRサーバーのデフォルト実装が提供されます。この実装では、セキュリティ情報(TuxedoユーザーID、パスワード、サービス・アクセス権限など)はLDAPリポジトリに格納されます。

各クライアントは、ATMIアプリケーションに参加するために有効なユーザー名とユーザー固有のパスワードを提供する必要があります。ユーザーのパスワードは、LDAPリポジトリに格納されているパスワードと一致する必要があります。各クライアントには適切な権限が付与され、その後、Tuxedoサービスに正常にアクセスできます。

デフォルトのXAUTHSVR実装でLDAPベースのセキュリティを有効にするには、次の手順を実行します。

1.

UBBCONFIGファイルの設定

2.

XAUTHSVRサーバー構成ファイルの設定

3.

LDAPリポジトリの設定

4.

認可キャッシュの設定

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

UBBCONFIGファイルの設定

1.

テキスト・エディタでUBBCONFIGを開きます。

2.

RESOURCESセクションで次のように設定します。

a.

SECURITYパラメータをUSER_AUTH、ACLまたはMANDATORY_ACLのいずれかの値に設定します。

b.

OPTIONSパラメータをEXT_AAに設定します。

c.

次のいずれか1つを実行します。

•

SECURITYパラメータがACLまたはMANDATORY_ACLAUTHSVCに設定された場合は、AUTHSVCを..AUTHSVC (XAUTHSVRサーバーによって通知されているサービス名)に設定します。

•

SECURITYパラメータがUSER_AUTHに設定された場合、AUTHSVCをAUTHSVC (XAUTHSVRサーバーによって通知されているサービス名)に設定します。

3.

SERVERSセクションでXAUTHSVRを設定します。

UBBCONFIGの構成例を次に示します。
* RESOURCES
SECURITY     ACL
AUTHSVC    ..AUTHSVC
OPTIONS       EXT_AA
 
*SERVERS 
XAUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y 
XAUTHSVRサーバー構成ファイルの設定

XAUTHSVRサーバー構成ファイルを使用してXAUTHSVRがLDAPリポジトリを探します。デフォルトの構成ファイルtpldap.xauthは$TUXDIR/udataobjディレクトリに格納されています。"-f"オプションを使用してカスタマイズした場所をXAUTHSVRサーバーに指定できます。XAUTHSVRサーバーでは、認証情報と認可情報を別のLDAPリポジトリに格納できます。それぞれ"-n"オプションと"-z"オプションを使用してATN構成ファイルを指定できます。これらすべての構成ファイルの形式は同じです。

表2-3は、XAUTHSVR構成ファイルのキーワードを示しています。

表2-3 XAUTHSVR構成ファイルのキーワード

キーワード

値の型

使用方法

FILE_VERSION

numeric

構成ファイルのバージョン。デフォルトは1です。これは1のままにしておく必要があります。

LDAP_VERSION

numeric

LDAPプロトコルのバージョン。有効な値は2および3です。デフォルトは3です。

BINDDN

string

LDAPサーバーへのバインドに使用されるDN。通常、DNはLDAP管理者を表します。デフォルトは"cn=Admin"です。

tpldapconfコマンドを使用するとBINDDNを作成できます。

BASE

string

LDAP検索ベース。デフォルトは"ou=people,ou=aa,dc=mydomain"です。ここで、mydomainは認証または認可セキュリティ・リポジトリのルート・ノードです。

PASSWORD

string

バインドDNのパスワード。これは必須のキーワードです。クリア・テキストのパスワードは暗号化されます。

tpldapconfコマンドを使用すると暗号化されたパスワードを作成できます。

LDAP_ADDR

string

ホスト名とポートを含むLDAPアドレスのカンマ区切りリスト。構文は[//]hostname[:port]です。ポートのデフォルト値は7001です。LDAP_ADDRを指定しない場合、XAUTHSVRはlocalhost:7001をLDAPサーバーに接続する場所とみなします。

UID_KW

string

認証セキュリティ・リポジトリでのユーザーの一意IDの検索で使用されるキーワード。デフォルト値は"uid"です。

PWD_KW

string

認証セキュリティ・リポジトリでのユーザーのパスワードの検索で使用されるキーワード。デフォルト値は"userPassword"です。

MEMBEROF_KW

string

グループ・メンバーシップの検索で使用されるキーワード。デフォルト値は"memberof"です。

様々なLDAPサーバーは、様々なキー名を使用して、ユーザーのグループ・メンバーシップを特定します。仮想メンバー・プラグインが有効な状態でOVDを使用するとき、キーワードは"memberof"です。

LDAPリポジトリの設定

LDAPリポジトリのセキュリティ情報の概要は次のとおりです。

•

inetOrgPerson: このオブジェクト・クラスは、ユーザーを表すエントリを保持します。定義は、属性"uid"の長さが30文字以内に制限されることを除き、RFC 4519および2798標準に従います。各Oracle Tuxedoユーザーはこのクラスのエントリとして保存されます。ユーザーIDとユーザー・パスワードを含むこの情報は、ユーザーレベル認証で使用されます。

•

groupOfUniqueNames: このオブジェクト・クラスは、名前付きオブジェクトのセットを表すエントリを保持します。セットの目的や保守に関連する情報も含まれます。この定義はRFC 4519標準に従います。このクラスにより、特定の種類の権限を付与されるユーザーのリストがグループ分けされます。グループはネストできます。親グループに付与される権限は子グループにも適用されます。

•

Orcljaznpermission: このオブジェクト・クラスは、表2-4に示す属性で構成されるtuxedo権限オブジェクトを保持します。このオブジェクトは2つの部分で構成されます。1つは権限です。これは、リソース・タイプ、ターゲット・リソース、ターゲット・リソース上のアクションを示します。もう1つは、この権限が付与される、割当て済のグループまたはユーザーです。

表2-4に、orcljaznpermissionクラスの属性の定義を示します。

表2-4 orcljaznpermissionクラスの属性

属性

タイプ

制約

説明

Cn

String:

単一値、一意、必須

権限名

Displayname

String:

String:

表示名

説明

String:

String:

説明

OrclJpsResourceTypeName

String:

単一値

保護するリソースのタイプ名。Tuxedoサービスを定義するときは、この属性を"SERVICE"に指定します。

Orcljaznpermissiontarget

String:

単一値

保護するリソースの名前。Tuxedoサービスを定義するときは、この属性をサービス名として指定します。

Orcljaznpermissionactions

String:

単一値

割り当てられたアクションをカンマで区切ったリスト。

Tuxedoサービスを定義するときは、この属性を"EXECUTE"に指定します。

認可キャッシュの設定

ATZパフォーマンスを向上させるために、新しいATZメカニズムとしてロールアップ・キャッシュが導入されています。このキャッシュには、すべてのTuxedoサーバーに対する特定のユーザーIDの権限が格納されます。様々なATZの要件を満たすために、このキャッシュは各Tuxedoサーバー・レベルで柔軟に構成できます。

3つの環境変数を使用して、キャッシュの基本動作を制御します。TUXCONFIGで特定のサーバー・エントリについてENVFILEパラメータを定義した後で、UBBCONFIGのSERVERSセクションで各Tuxedoサーバー・エントリにこれらの環境変数を定義できます。

TMATZPRIVILEGEMAX

これは、権限エントリの最大数を指定します。キャッシュ内の権限数がこのしきい値に達すると、新しいエントリによって古いエントリが置換されます。権限の残りの存続時間を評価することにより、Tuxedoは、ATZキャッシュ内で使用される可能性が最も低いエントリを選択できます。この環境変数が0に設定されると、TuxedoサーバーのATZキャッシュは無効になり、すべてのATZリクエストはATZサービスにディスパッチされます。この環境変数が明示的に定義されない場合、デフォルト値は100です。有効値の範囲は0 - 32767です。ATZキャッシュ内の1つの権限エントリのサイズは約50バイトです。

TMATZRESOURCEMAX

これは、特定のTuxedoサーバーに割り当てられるリソース・エントリの最大数を指定します。キャッシュ内のリソース数がこのしきい値に達すると、リソースも新しい権限もキャッシュに追加されなくなります。リソースに対するその後のアクセス・リクエストは、使用可能なリソース・スロットが見つかるまでATZサーバーにルーティングされます。Tuxedoは、キャッシュされた権限によって占有される各リソース・エントリの参照番号を保持します。特定のリソース・エントリを占有する権限がないとき、そのエントリはキャッシュからクリアされます。

この環境変数が明示的に定義されない場合、値は、現在通知されているサービスの数に設定されます。また、TMATZPRIVILEGEMAXの値は、TMATZRESOURCEMAXの値以上に設定する必要があります。そうしないと、TMATZPRIVILEGEMAXはTMATZRESOURCEMAXと等しい値に設定されます。

有効値の範囲は0 - 32767です。ATZキャッシュ内の1つのリソースエントリのサイズは約148バイトです。

この環境変数が0に設定されると、TuxedoサーバーのATZキャッシュは無効になり、すべてのATZリクエストはATZサービスにディスパッチされます。

TMATZEXP

これは、特定の権限の最大存続時間(分単位)を指定します。権限の存続時間がこのしきい値に達すると、その権限はキャッシュから除去されます。Tuxedoサーバーのこの環境変数が0に設定されると、Tuxedoサーバーに格納されるすべての権限の存続時間は無制限になり、期限切れになりません。この環境変数が明示的に定義されない場合、デフォルト値は10です。有効値の範囲は0 - 525600です。525600は、キャッシュでの権限の存続期間1年間に相当します。

次の例は、特定のTuxedoサーバーでATZキャッシュによって使用される合計メモリー・サイズを計算する方法を示します。

10個の/Qメッセージ・キューにアクセスするサーバーがあるとします。これは10個のリソース・エントリに対応しており、このサーバーを呼び出す潜在的なユーザーは100人です。このため、TMATZRESOURCE値は10、MAX TMATZPRIVILEGEMAX値は1000と仮定します。

使用メモリー・サイズの計算式([リソース・エントリの最大数] * [リソース・エントリのサイズ] + [権限エントリの最大数]*[権限エントリのサイズ])

前述の例の結果は次のとおりです。

(10*148 + 1000*50)= 51480 (51 KB)

関連項目

•

1-44ページの「デフォルトの認証と認可の管理」

•

2-65ページの「デフォルトの認証と認可の管理」

OESのセキュリティ・サービスを有効にする方法

1.

OESサーバーおよびクライアント(セキュリティ・モジュール)をインストールします。

注意:

Oracle Entitlement Server (OES)クライアント11.1.2.0の使用は動作保証されています。

2.

OESサーバーに接続するようにOES Javaクライアントを構成します。

3.

OESサーバーでアプリケーションを作成し、リソース・タイプ、リソースおよびポリシーを作成して認可を指定します。

注意:

OES側で異なるポリシーを定義することにより、ユーザーは同じ名前を持つ異なるタイプのリソースを認可できるようになります。各ポリシーは1つのリソース・タイプのみを認可します。たとえば、OESという名前のサービスと、OESという名前の/Qキューを認可するために、ユーザーはそれぞれを認可する2つのポリシーをOES側で定義できます。

4.

認可テンプレート・ファイルを構成して(構成済OESサーバーのアプリケーション名とjps-config.xmlの正確なフル・パス名を構成)、OESで構成した内容を示します。

5.

EAUTHSVRサーバーを構成します。

•

tux.envを実行して、ライブラリ・パスにlibjvm.soを設定します。

•

oes-client.jarをCLASSPATHに設定します。

6.

認証サーバーを構成します。

EXT_AAをOPTIONSに、..AUTHSVCをUBBCONFIG RESOURCESに構成して、使用するサービスを認証します。

詳細は、Oracle Identity and Access Managementインストレーション・ガイドを参照してください。

Kerberos認証プラグインの使用

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

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

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

•

Kerberosプラグイン

•

Kerberosプラグインの事前構成

•

Kerberosプラグインの構成

Kerberosプラグイン

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

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

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

•

Windows 2000/2003サーバーに同梱のMicrosoft Kerberos

•

HPで提供されているHP-UX(PA-RISC)のKerberos Vシステム

•

Sun Microsystemsで提供されているSolaris 9 (SPARC)のKerberos Vシステム

Kerberosプラグインの機能

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

•

Tuxedoネイティブ・クライアントとサーバーの間の認証

•

Tuxedo ACLセキュリティ・メカニズムの完全なサポート

注意:

Tuxedoワークステーション・クライアントとワークステーション・ハンドラのセキュリティ・プロトコル間の認証、2つのドメイン・ゲートウェイとCORBAコンポーネントの間の認証はサポートされていません。

Kerberosプラグインの事前構成

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

•

サポートされているシステムが適切なKerberos設定で実行されていること

•

ユーザー/サービス・アカウントが適切に設定されていること

•

Kerberos認証サーバー・キー表が、UNIXで適切に作成されていること

•

UNIXとWindowsの間のKerberosの相互運用性が適切に設定されており、異種(UNIXとWindowsが混在している)環境で必要な場合は動作検証されていること

Kerberosプラグインの構成

ここでは、Kerberosプラグインの設定と実行に必要な構成情報について説明します。

1.

Kerberosプラグインの構成

2.

KAUTHSVRの構成

3.

Tuxedoネイティブ・クライアントの構成

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

Kerberosプラグインの構成

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

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

リスト2-2 UNIXの登録
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
リスト2-3 Windowsの登録
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レルム名を指定する必要があります。

名前の形式は次のとおりです。

•

UNIX TuxedoクライアントはGSS形式を使用してKAUTHSVRにアクセスします。

•

WindowsTuxedoクライアントは、必ず完全なKerberosレルム名を使用してKAUTHSVRにアクセスします。

KAUTHSVRPRINCは、環境変数として設定することもできます。

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

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

リスト2-4 デフォルト・プラグイン設定を回復する
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の構成

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

次に、UBBCONFIGファイルによるKAUTHSVRの構成について、UNIXとWindows双方の例を示します。

リスト2-5 UBBCONFIG KAUTHSVRの構成(UNIXの場合)
*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形式を使用する必要があります。

リスト2-6 UBBCONFIG KAUTHSVRの構成(Windowsの場合)
*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つの引数を使用する必要があります。

•

SEC_PRINCIPAL_NAMEは、(-pオプションで示した)サーバー・プリンシパル名ではなくKAUTHSVRを表します。

•

SEC_PRINCIPAL_PASSVARは内部のパスワード変数です。これは、tmloadcfがTUXCONFIGファイルを作成する際に必要な実際のパスワードではありません。tmloadcfパスワード入力は、WindowsドメインのKAUTHSVRアカウント・パスワードと同じものでなくてはなりません。

Windowsプラットフォームで動作しているKAUTHSVRでは、完全なKerberosレルム名を使用する必要があります。

Tuxedoネイティブ・クライアントの構成

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

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

制限

•

Kerberosプラグインは、プラグインがインストールされ、epif*コマンドでTuxedoに登録されているシステムでのみ動作します。libkrb5atnがTuxedoに登録されていない場合でも、デフォルト・プラグインおよびデフォルトTuxedoセキュリティ・メカニズムは有効です。KAUTHSVRでは、Kerberos認証に加えて、完全なAUTHSVR機能を使用できます。

•

KerberosプラグインがWSHを実行しているシステムで構成されている場合でも、このシステムに接続しているワークステーション・クライアントは、Tuxedoのデフォルト・セキュリティ・メカニズムを使用します。これは、ワークステーション・クライアントとWSHの間のプロトコルが、この機能による影響を受けないせいです。

•

CORBAネイティブ・クライアントもKerberosサポートを利用できますが、Kerberosを使用したCORBAリモート・クライアントはサポートされていません。Kerberosプラグインがインストールされている場合、ISHはエラーを報告します。

注意:

Tuxedoワークステーション・クライアントとワークステーション・ハンドラのセキュリティ・プロトコル間の認証、2つのドメイン・ゲートウェイとCORBAコンポーネントの間の認証はサポートされていません。

関連項目

•

KAUTHSVR(5)

•

MITによるKerberosの概要(tap://web.mit.edu/kerberos/wow/)

•

MicrosoftによるKerberosのホワイト・ペーパーとガイド(tap://www.microsoft.com/windows2000/technologies/security/kerberos/default.asp)

•

RFC 1510, Kerberosプロトコル(tap://www.ietf.org/raft/rfc1510.txt)

•

RFC 2743, GSSAPI (tap://www.ietf.org/raft/rfc2743.txt)

•

RFC 1509, GSSAPI, c-bindings.(http://www.ietf.org/raft/rfc1509.txt)

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

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

•

サイン - 署名をTuxedo型付きバッファに割り当てます

•

封印 - Tuxedo型付きバッファを暗号化します

•

エンベロープ - Tuxedo型付きバッファに関連付けられているユーザー署名と暗号化情報へのアクセスを可能にします

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

•

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

•

Cert-C PKI暗号化プラグインの事前構成

•

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

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

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

Cert-C PKI暗号化プラグインの事前構成

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

•

構成されたLDAPサーバーにアクセスできること

•

LDAPに格納されたユーザー証明書がcn=user nameという形式で入力されていること

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

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

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

•

証明書ルックアップの構成

•

鍵管理の構成

•

証明書解析の構成

•

証明書検証の構成

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

証明書ルックアップの構成

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

ldapUserCertificate

プラグインがユーザー証明書を取得できる場所を識別するためのLDAPサーバー構成パラメータ。LDAPホストのネットワーク・アドレスは、このパラメータで文字列変数として指定されます。また、ここにはTCP LDAPポート番号も格納されます。このパラメータの構文はLDAP:URLです。例:

ldapUserCertificate=ldap://sagamore:389

この例では、LDAPサーバーがsagamoreと呼ばれるマシン上にあり、ポート389をリスニングしていることをCert-Cプラグインに伝えています。

ldapBaseObject

LDAP検索が開始されるベースDNを識別するためのLDAPサーバー構成パラメータ。例:

ldapBaseObject="ou=Engineer Test,o=ABC Company,c=US"

この例では、ディレクトリ情報ツリー"ou=Engineer Test, o=ABC Company, c=US"から検索を開始します

ldapFilterAttribute

サブジェクト名で証明書を取得する際に、LDAP検索で使用する検索フィルタを識別するためのLDAPサーバー構成パラメータ。このパラメータは文字列変数で、ldapBaseDNAttributeと同じ構文で指定します。例:

ldapFilterAttribute="cn"

この例では、フィルタとして"cn"を使用するようにCert-Cプラグインに通知します。

ldapBaseDNAttribute

ベースDNを作成するためにLDAP検索で使用するLDAPサーバー構成パラメータ。このパラメータは、「c, o」のように、DN属性をカンマで区切って示す文字列変数です。必要に応じて、カンマの後にスペースを挿入できます。例:

ldapBaseDNAttribute="c, o, ou, cn"

この例では、DNを検索用に構築する際に"c"、"o"、"ou"、"cn"の属性を使用するようにCert-Cプラグインに通知します。

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

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

リスト2-7 OpenLDAPコマンド
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'.
内容は次のとおりです。

•

<suffix>は、共有ライブラリの適切な接尾辞です(例: Windowsの場合はlibplugin.dll、Solarisの場合はlibplugin.so.71)。

•

ldap_host_nameは、LDAPサーバーが実行されているホストの名前です。

•

ldap_portは、LDAPサーバーのポート番号です(例: userCertificateLdap=ldap:/cerebrum:389/)。

•

your_ldap_baseは、LDAP DITの起点です(例: ldapBaseObject='ou=Accounting,o=ABC Company,c=US')。

注意:

場合によっては、$TUXDIR/udataobj/securityにあるbea_ldap_filter.datファイルを変更する必要もあります。

リスト2-8に、フィルタの例を示します。

リスト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"
鍵管理の構成

秘密鍵の場所は、キー管理インタフェース用に指定する必要がある構成パラメータでのみ指定します。

decPassword

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

decPassword="abc123"

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

注意:

decPasswordとprivateKeyDirをオーバーライドするには、tpkey_open(3c)のidentity_proofおよびlocationパラメータを使用します。

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ファイルのみが検索対象になります。

証明書解析の構成

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

注意:

証明書は、DER形式のX.509互換にする必要があります。

証明書検証の構成

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

caCertificateFile

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

注意:

存在する証明書検証チェーン・レベルは1つだけです。つまり、すべてのユーザー証明書は、caCertificateFileで構成されたルートCAによって直接発行されます。

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レジストリ・データベースを変更するサンプル・コマンドを示します。

注意:

UNIXプラットフォームでは、次のように置き換える必要があります。

•

Windowsで使用されるcertctux.dllではなく、ファイル名libcertctuxにプラットフォーム固有の動的ライブラリの拡張子を付けたものを使用します。例:

Solarisの場合: libcertctux.so.71
HP-UXの場合: libcertctux.sl

•

ファイルURLをUNIX形式に変更します。

リスト2-9 Windowsで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

制限

•

識別名の"cn"属性は、証明書ルックアップ用のキーとして使用されるので、DNには"cn="属性を含める必要があります。

•

名前をX.509 v3 KCに配置できる場所は2つあります。

•

1つはベースPKCのサブジェクト・フィールドで、しばしば識別名(DN)フィールドと呼ばれます。

•

もう1つはsubjectAltName拡張機能です。このプラグインでは、subjectAltName拡張機能を使用できません。

注意:

ワイルドカードを名前に使用することはできません。サブジェクト・フィールドを空にすることはできません。

•

次の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の情報を取得できます。

TPKEY_AUTOSIGN|TPKEY_DECRYPT: ENCRYPT_ALG、ENCRYPT_BITS、SIGNATURE_ALG、またはSIGNATURE_BITSの情報を取得できます。

関連項目

tpkey_open(3c)

パラメータ名	説明	設定
UBBCONFIGのSEC_PRINCIPAL_NAME (TM_MIBのTA_SEC_PRINCIPAL_NAME)	アプリケーションの起動時に、ATMIアプリケーション内のそれぞれのWSH、ドメイン・ゲートウェイ、およびサーバー・プロセスは、認証プラグインを呼び出して、SEC_PRINCIPAL_NAMEで指定されたセキュリティ・プリンシパル名のセキュリティ資格証明を取得します。*	1から511文字。プリンシパル名が構成階層のどのレベルでも指定されない場合は、UBBCONFIGファイルのDOMAINIDの文字列がデフォルト値になります。
ローカル・ドメイン・アクセス・ポイントを示すDMCONFIGのCONNECTION_PRINCIPAL_NAME (DM_MIBにあるLACCESSPOINTのTA_DMCONNPRINCIPALNAME)	アプリケーションの起動時に、ATMIアプリケーション内の各ドメイン・ゲートウェイ・プロセスは、認証プラグインをもう一度呼び出して、CONNECTION_PRINCIPAL_NAMEで指定された接続プリンシパル名のセキュリティ資格証明を取得します。*	1から511文字。接続プリンシパル名を指定しない場合は、DMCONFIGファイルで指定されたローカル・ドメイン・アクセス・ポイントを示すACCESSPOINTID **の文字列がデフォルト値になります。
* システム・プロセスが資格証明を取得する方法、および資格証明が必要な理由については、次の項で説明します。 **ACCESSPOINTIDパラメータはDOMAINIDともいいます。

プロセス	相互運用性を実現できる場合(CLOPT -t)	相互運用性を実現できない場合
ワークステーション・ハンドラ(WSH)	WSHは、アプリケーションに参加するためのリクエストをリリース7.1より前のワークステーション・クライアントから受け取ると、リリース7.1より前の認証プロトコルを使用してクライアントを認証します。次に、リクエスト内で指定されているユーザー名に基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンと監査トークンを取得します。 WSHは、認証されたワークステーション・クライアントからサービス・リクエストを受け取ると、クライアント・リクエストにトークンを添付し、リクエスト先のサーバーに転送します。	WSHは、アプリケーションに参加するためのリクエストをリリース7.1より前のワークステーション・クライアントから受け取っても拒否します。新しいWSHと古いワークステーション・クライアントとの間の通信は実現できません。
ドメイン・ゲートウェイ(GWTDOMAIN)	ドメイン・ゲートウェイは、リリース7.1より前のリモート・ドメイン・ゲートウェイとの接続を確立すると、リリース7.1より前の認証プロトコルを使用してそのリモート・ドメイン・ゲートウェイを認証し、ネットワーク接続を確立します。ドメイン・ゲートウェイは、古いドメインからのクライアント・リクエストを受け取ると、リモート・ドメイン・アクセス・ポイントに構成されたLOCAL_PRINCIPAL_NAME (デフォルトはACCESSPOINTID)のID に基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンおよび監査トークンを取得します。次に、これらのトークンをクライアント・リクエストに添付し、リクエスト先のサーバーに転送します。クライアントには、LOCAL_PRINCIPAL_NAME IDと同じアクセス・パーミッションがあります。アウトバウンドのクライアント・リクエストの場合、ドメイン・ゲートウェイは、リクエストに添付されたトークンを取除いてから、そのリクエストをアプリケーション・キーとともに古いドメインに送信します。	ドメイン・ゲートウェイは、7.1より前のリリースのリモート・ドメイン・ゲートウェイとの接続を設定しません。新しいドメインと古いドメインとの間の通信は実現できません。
システムまたはアプリケーション・サーバー	サーバーは、リリース7.1より前のOracle Tuxedoソフトウェアを実行するリモート・クライアントからリクエストを受け取ると、クライアントに割り当てられたアプリケーション・キーに基づき、ユーザー偽装関数を呼び出してクライアントの認可トークンと監査トークンを取得します。次に、サーバーは、クライアントが認可チェックにパスしたとみなしてクライアント・リクエストを実行します。	サーバーは、Oracle Tuxedoリリース7.1より前のソフトウェアを実行するリモート・クライアントからリクエストを受け取っても拒否します。新しいサーバーと古いクライアントとの間の通信は実現できません。

手順	説明
1	LDAP対応ディレクトリ・サービスを構成します。Oracle Tuxedo製品のインストール時に、LDAPサーバーの名前を入力する必要があります。
2	SSLプロトコルを使用するためのライセンスをインストールします。
3	Oracle Tuxedoアプリケーションのデジタル証明書および秘密鍵を認証局から取得します。
4	Oracle Tuxedoアプリケーションと認証局のデジタル証明書をLDAP対応ディレクトリ・サービスで公開します。
5	Tuxedoサーバー・プロセスのSEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARパラメータをUBBCONFIGファイルで定義します。
6	UBBCONFIGパラメータ、DMCONFIGパラメータ、WSL CLOPT、JSL CLOPT、またはISL CLOPTの設定を変更してSSLをオンにします。
7	適切な構成ファイルまたはサーバーCLOPTで、SSL通信用のポートを定義します。
8	Oracle Tuxedoアプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル(trust_ca.cer)を作成します。
9	tmloadcfコマンドやdmloadcfコマンドを使用して適切な構成ファイルがロードされるように変更します。
10	オプションで、Oracle Tuxedo製品のピア規則ファイル(peer_val.rul)を作成します。
11	オプションで、社内のディレクトリ階層に合せてLDAP検索フィルタ・ファイルを変更します。

実行	目的	エントリが格納されているファイル名
tpusradd(1)	追加	tpusr
tpusrmod(1)	変更
tpusrdel(1)	削除
tpgrpadd(1)	追加	tpgrp
tpgrpmod(1)	変更
tpgrpdel(1)	削除

実行	目的
tpacladd(1)	エントリの追加
tpaclmod(1)	エントリの変更
tpacldel(1)	エントリの削除

キーワード	値の型	使用方法
FILE_VERSION	numeric	構成ファイルのバージョン。デフォルトは1です。これは1のままにしておく必要があります。
LDAP_VERSION	numeric	LDAPプロトコルのバージョン。有効な値は2および3です。デフォルトは3です。
BINDDN	string	LDAPサーバーへのバインドに使用されるDN。通常、DNはLDAP管理者を表します。デフォルトは"cn=Admin"です。 tpldapconfコマンドを使用するとBINDDNを作成できます。
BASE	string	LDAP検索ベース。デフォルトは"ou=people,ou=aa,dc=mydomain"です。ここで、mydomainは認証または認可セキュリティ・リポジトリのルート・ノードです。
PASSWORD	string	バインドDNのパスワード。これは必須のキーワードです。クリア・テキストのパスワードは暗号化されます。 tpldapconfコマンドを使用すると暗号化されたパスワードを作成できます。
LDAP_ADDR	string	ホスト名とポートを含むLDAPアドレスのカンマ区切りリスト。構文は[//]hostname[:port]です。ポートのデフォルト値は7001です。LDAP_ADDRを指定しない場合、XAUTHSVRはlocalhost:7001をLDAPサーバーに接続する場所とみなします。
UID_KW	string	認証セキュリティ・リポジトリでのユーザーの一意IDの検索で使用されるキーワード。デフォルト値は"uid"です。
PWD_KW	string	認証セキュリティ・リポジトリでのユーザーのパスワードの検索で使用されるキーワード。デフォルト値は"userPassword"です。
MEMBEROF_KW	string	グループ・メンバーシップの検索で使用されるキーワード。デフォルト値は"memberof"です。様々なLDAPサーバーは、様々なキー名を使用して、ユーザーのグループ・メンバーシップを特定します。仮想メンバー・プラグインが有効な状態でOVDを使用するとき、キーワードは"memberof"です。

属性	タイプ	制約	説明
Cn	String:	単一値、一意、必須	権限名
Displayname	String:	String:	表示名
説明	String:	String:	説明
OrclJpsResourceTypeName	String:	単一値	保護するリソースのタイプ名。Tuxedoサービスを定義するときは、この属性を"SERVICE"に指定します。
Orcljaznpermissiontarget	String:	単一値	保護するリソースの名前。Tuxedoサービスを定義するときは、この属性をサービス名として指定します。
Orcljaznpermissionactions	String:	単一値	割り当てられたアクションをカンマで区切ったリスト。 Tuxedoサービスを定義するときは、この属性を"EXECUTE"に指定します。