1. ATMIアプリケーションにおけるセキュリティの使用
  2. セキュリティの管理

2 セキュリティの管理

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

2.1 セキュリティの管理とは

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

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

  • 認証
  • 認可
  • 監査
  • リンク・レベルの暗号化
  • TLS暗号化
  • 公開キーによるセキュリティ機能
アプリケーション管理者はセキュリティ機能を構成できます(ただし、例外が1つあります)。その例外は監査で、次の図に示すように監査は構成できません。

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

ATMIのセキュリティの管理の図について説明します。

関連項目:

親トピック: セキュリティの管理

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

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

親トピック: セキュリティの管理

2.3 Oracle Tuxedoレジストリの設定

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

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

親トピック: セキュリティの管理

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

親トピック: Oracle Tuxedoレジストリの設定

2.3.2 プラグインの登録

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

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

  • epifreg - プラグインの登録
  • epifunreg - プラグインの登録解除
  • epifregedt - レジストリ情報の編集

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

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

関連項目:

親トピック: Oracle Tuxedoレジストリの設定

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

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

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

  • 構成ファイル(UBBCONFIG)を編集する
  • TM_MIBの変更

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

親トピック: セキュリティの管理

2.4.1 構成ファイルの編集

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

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

親トピック: セキュリティ用のATMIアプリケーションの構成

2.4.2 TM_MIBの変更

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

関連項目:

親トピック: セキュリティ用のATMIアプリケーションの構成

2.5 管理環境の設定

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

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

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

ノート:

親トピック: セキュリティの管理

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

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

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

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

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

親トピック: 管理環境の設定

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

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

  • ファイルおよびIPCリソースに対するアクセスをアプリケーション管理者に制限します。
  • setuidユーティリティを使用して、信頼性のあるクライアント・プログラムを必ず管理者のパーミッションで実行します。
  • 最も高いレベルのオペレーティング・システムのセキュリティを実現するには、ワークステーション・クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション・サーバーおよび管理プログラムを実行するマシンではクライアント・プログラムを実行できないようにします。
  • 前述のすべての方法をATMIのセキュリティと組み合せて使用し、リクエストの発行元であるクライアントをアプリケーション側で識別できるようにします。

2.6 認証の管理

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

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

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

図2-2 高信頼性委任型認証モデル


高信頼性委任型認証モデルの図

ノート:

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

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

関連項目:

親トピック: セキュリティの管理

2.7 プリンシパル名の指定

管理者は、次の構成パラメータを使用して、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ファイルを確認してください。

親トピック: セキュリティの管理

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

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

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


アプリケーション起動時の資格証明とトークンの取得の図

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

親トピック: プリンシパル名の指定

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

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

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

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

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

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

ノート:

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

親トピック: プリンシパル名の指定

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

次の例は、UBBCONFIGのSEC_PRINCIPAL_NAMEパラメータを使用してセキュリティ・プリンシパル名を指定する方法を示しています。CONNECTION_PRINCIPAL_NAMEパラメータを使用して、DMCONFIGファイルの接続プリンシパル名を指定する例については、「リンクを確立するためのDMCONFIGのエントリ例」を参照してください。 

*RESOURCES
         SEC_PRINCIPAL_NAME    "Tommy"
              .
              .
              . 
*SERVERS 
"TMQUEUE"     SRVGRP="QUEGROUP"     SRVID=1
CLOPT="-t -s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME="TOUPPER"

ノート:

親トピック: プリンシパル名の指定

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

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

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


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

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

ノート:

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

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


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

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

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


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

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

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

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


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

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

ノート:

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

親トピック: セキュリティの管理

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

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

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


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

親トピック: 相互運用性のポリシーの指定

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

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

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

2.8.1.2 ドメイン・ゲートウェイ側で古いクライアントのIDを確認する

CLOPT -tオプションが指定されている場合、ドメイン・ゲートウェイは、リモート・ドメイン・アクセス・ポイントに対して構成されたLOCAL_PRINCIPAL_NAME文字列を使用して、古いクライアントのIDを確認します。ドメイン・ゲートウェイは、ローカルのBDMCONFIGファイル(バイナリ形式のDMCONFIG(5)ファイル)のDM_REMOTEセクションで、リモート・ドメイン・アクセス・ポイントのLOCAL_PRINCIPAL_NAME文字列を検索します。このオプションを指定しない場合は、リモート・ドメイン・アクセス・ポイントのACCESSPOINTID文字列がデフォルト値になります。ドメイン・ゲートウェイは、ユーザー偽装関数を呼び出すときにプリンシパル名としてLOCAL_PRINCIPAL_NAME文字列を使用します。

デフォルトの認証プラグインの場合、ユーザー偽装関数は、ローカルのtpusrファイルからLOCAL_PRINCIPAL_NAME文字列および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、その文字列(ID)とアプリケーション・キーを組み込みます。

2.8.1.3 サーバー側で古いクライアントのIDを確認する

CLOPT -tオプションが指定されている場合、サーバーは、クライアントに割り当てられたアプリケーション・キーを使用して、古いクライアントのIDを確認します。サーバーが受信したクライアント・リクエストには、クライアントに割り当てられたアプリケーション・キーが含まれています。サーバーは、ローカルのtpusrファイルからアプリケーション・キーと関連する名前を検索し、ユーザー偽装関数を呼び出すときにプリンシパル名としてその名前を組み込みます。

デフォルトの認証プラグインの場合、ユーザー偽装関数は、ローカルのtpusrファイルから名前および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、名前とアプリケーション・キーを組み込みます。

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

親トピック: 相互運用性のポリシーの指定

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

次の例は、ワークステーション・リスナー(WSL)によって制御されるすべてのWSHで相互運用性が実現できることを示しています。

*SERVERS
         WSL    SRVGRP="group_name"  SRVID=server_number ...
         CLOPT="-A -t ... "

ノート:

親トピック: 相互運用性のポリシーの指定

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

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

  1. イニシエータおよびターゲットのドメイン・ゲートウェイは、TLSまたはリンクレベル暗号化(LLE)のmin-max値を交換します。これらの値は、ゲートウェイ間のリンクにTLSまたはLLEを設定するために使用されます。TLSを使用している場合は、イニシエータおよびターゲットのドメイン・ゲートウェイも、TLS証明書を使用して相互に認証し合います。LLEについては、「リンク・レベルの暗号化」を参照してください。TLSの詳細は、「TLS暗号化」を参照してください。
  2. イニシエータおよびターゲットのドメイン・ゲートウェイは、セキュリティ・トークンを交換することにより、認証し合います。このとき、双方でOracle Tuxedoリリース7.1以上のソフトウェアを実行していると想定します。

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

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

パラメータ名 説明 設定
DMCONFIGのCONNECTION_PRINCIPAL_NAME (DM_MIBのTA_DM CONNPRINCIPALNAME) このパラメータが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 デフォルトの認証を使用してドメイン間にリンクを確立する


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

ノート:

上の図の「資格証明」は、ローカル・ドメイン・アクセス・ポイントに対して構成された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文字列と一致しなければなりません。

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

親トピック: セキュリティの管理

2.9.1 リンクを確立するための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 ACLポリシーの設定

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

パラメータ名 説明 設定
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ポリシーの確立


ローカルな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ポリシーの確立


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

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

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


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

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

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

親トピック: セキュリティの管理

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

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

  1. 内部のユーザー偽装関数を呼び出して、リモート・ドメイン・アクセス・ポイントに構成されたLOCAL_PRINCIPAL_NAMEのIDに基づき、クライアントの認可トークンと監査トークンを取得します。
  2. 取得したトークンを使用して、すでにクライアント・リクエストに添付されているトークンを上書きします。
  3. リクエストを送信先のサーバーに転送します。

ユーザー偽装関数の詳細は、「古いクライアントのIDの確認」を参照してください。

親トピック: ACLポリシーの設定

2.10.2 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"

ノート:

親トピック: ACLポリシーの設定

2.11 資格証明ポリシーの設定

管理者は、次の構成パラメータを使用して、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に設定すると、このリモート・ドメイン・アクセス・ポイントに送信されるローカル・サービス・リクエストから資格証明が削除されません。

親トピック: セキュリティの管理

2.12 認可の管理

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

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

ノート:

親トピック: セキュリティの管理

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

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

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

  • ワークステーション・クライアントからワークステーション・ハンドラ(WSH)へのリンク
  • ブリッジ間のリンク
  • 管理ユーティリティ(tmbootなど)またはtlistenとのリンク
  • ドメイン・ゲートウェイ間のリンク

親トピック: セキュリティの管理

2.13.1 LLEのmin値とmax値の理解

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

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

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

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

親トピック: リンク・レベルの暗号化の管理

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

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

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

ノート:

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

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

  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ファイルがロードされます。

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

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

親トピック: リンク・レベルの暗号化の管理

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

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

管理者は、ブリッジ・サーバーが置かれたATMIアプリケーション内の各マシンに対して、UBBCONFIGファイルのNETWORKセクションにエントリを作成します。LLEのminおよびmaxパラメータのデフォルト値をオーバーライドする場合は、ブリッジ・サーバーのオプションのランタイム・パラメータであるMINENCRYPTBITSおよびMAXENCRYPTBITSを指定する必要があります。(詳細は、「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)に関する項を参照してください。

親トピック: リンク・レベルの暗号化の管理

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

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

tlistenリンクにLLEを構成するには、「ブリッジ間のリンクに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)」を参照してください。

親トピック: リンク・レベルの暗号化の管理

2.13.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を指定する必要があります。(詳細は、「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 is replaced with a local domain access point identifier, and RDOM is replaced with a remote domain access point identifier
  3. dmloadcf(1)を実行して構成をロードします。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。

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

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

関連項目:

親トピック: リンク・レベルの暗号化の管理

2.14 TLS暗号化の管理

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

親トピック: セキュリティの管理

2.14.1 TLSのmin値とmax値の理解

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

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

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

親トピック: TLS暗号化の管理

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

ワークステーション・クライアントのリンクにTLSを構成するには、次のステップに従います:

  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はTLS接続のみを試行します。それぞれ別のポートが使用されている場合は、同じWSLが非TLS接続とTLS接続の両方を試行できます。

    WSCは、SEC_PRINCIPAL_LOCATION、SEC_PRINCIPAL_NAME、SEC_PRINCIPAL_PASSWORD環境変数のいずれかまたは複数を状況に応じて設定する必要があります。

    TLSを使用するすべてのワークステーション・クライアントは、WSHによって提供される資格証明の確認に使用するために、信頼性のある証明書のリストを指定する必要があります。従来のセキュリティ資格証明を使用する場合、場所はプラグイン・フレームワークのcertificate_validationインタフェースで指定されます。環境変数を設定する必要はありません。セキュリティ資格証明のためにOracle Walletを使用する場合、信頼性のある証明書はOracle Walletに格納されます。「実行時のOracle Walletの作成」で説明するように、ウォレットの場所を指定するためにSEC_PRINCIPAL_LOCATIONおよびSEC_PRINCIPAL_NAME環境変数が使用されます。SEC_PRINCIPAL_PASSWORD環境変数は、ウォレットを開くために使用されます。

    ノート:

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

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

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

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

親トピック: TLS暗号化の管理

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

ブリッジ間のリンクにTLSを構成するには、次のステップに従います:

  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ファイルがロードされます。

親トピック: TLS暗号化の管理

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

tlistenリンクにTLSを構成するには、「ブリッジ間のリンクにSSLを構成する方法」で説明したステップに従います。次のコマンドを入力する必要があります。 

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

ノート:

-sオプションは、LLE接続ではなくTLS接続であることを示します。

-c、-n、および-pオプションは、TLSセキュリティ・プリンシパル情報を指定するためのもので、UBBCONFIGファイルのSEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL PASSVARと一致していなければなりません。

親トピック: TLS暗号化の管理

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

ドメイン・ゲートウェイのリンクにTLSを構成するには、次のステップに従います:

  1. ATMIアプリケーションのMASTERマシンで作業しており、ATMIアプリケーションが非アクティブであることを確認します。
  2. テキスト・エディタでDMCONFIGを開き、DM_TDOMAINセクションに次の行を追加します。 
    *DM_TDOMAIN 
         # SSL DEFAULT: NWPROTOCOL={SSL|SSL_ONE_WAY}
         SSL_RENEGOTIATION = [value]
     # 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 is replaced with a local domain access point identifier, and RDOM is replaced with a remote domain access point identifier.
  3. SEC_PRINCIPAL_NAME、 SEC_PRINCIPAL_LOCATION 、およびSEC_PRINCIPAL_PASSWORD をUBBCONFIGファイルに指定する必要があります。
  4. dmloadcf(1) を実行して構成をロードします。dmloadcfコマンドを実行すると、DMCONFIGが解析され、BDMCONFIG変数が指す場所にバイナリ形式のBDMCONFIGファイルがロードされます。

親トピック: TLS暗号化の管理

2.14.6 TLSプロトコル用の開発プロセス

TuxedoアプリケーションでTLSプロトコルを使用するのは、主に管理プロセスです。次の表は、TLSプロトコルを使用できるようにインフラストラクチャを設定し、アプリケーション内のサーバーおよびクライアントでTLSプロトコルが使用されるように構成するための管理ステップについて説明します。

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

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

ノート:

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

表2-2 TLSプロトコル用の管理ステップ

ステップ 説明
1 LAP対応ディレクトリ・サービスを構成します。Oracle Tuxedo製品のインストール時に、LDAPサーバーの名前を入力する必要があります。
2 TLSプロトコルを使用するためのライセンスをインストールします。
3 Oracle Tuxedoアプリケーションのデジタル証明書および秘密キーを認証局から取得します。
4 Oracle Tuxedoアプリケーションと認証局のデジタル証明書をLAP対応ディレクトリ・サービスで公開します。
5 Tuxedoサーバー・プロセスのSEC_PRINCIPAL_NAME、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARパラメータ UBBCONFIGファイルで定義します。
6 UBBCONFIGパラメータ、DMCONFIGパラメータ、WSL CLOPT、JSL CLOPT、またはISL CLOPTの設定を変更してTLSをオンにします。
7 適切な構成ファイルまたはサーバーCLOPTで、TLS通信用のポートを定義します。
8 Oracle Tuxedoアプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル(trust_ca.cer)を作成します。
9 tmloadcfコマンドやdmloadcfコマンドを使用して適切な構成ファイルがロードされるように変更します。
10 オプションで、Oracle Tuxedo製品のピア規則ファイル(peer_val.rul)を作成します。
11 オプションで、社内のディレクトリ階層に合せてLDAP検索フィルタ・ファイルを変更します。

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

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

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


TuxedoアプリケーションでTLSプロトコルを使用する構成の図

親トピック: TLS暗号化の管理

2.14.7 Oracle Walletの作成

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

  • owmグラフィカル・ツールの使用(Oracle Databaseをインストールしているユーザー向け)
  • orapkiコマンド行ツールの使用(Oracle Databaseをインストールしているユーザー向け)
  • opensslまたは他のサード・パーティ・ツールの使用
  • 実行時に自動作成(Tuxedo 11g以前のリリースで使用されるセキュリティ資格証明が変換される)

親トピック: TLS暗号化の管理

2.14.7.1 orapkiを使用したOracle Walletの作成

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

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

親トピック: Oracle Walletの作成

2.14.7.2 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 Spass: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の作成

2.14.8 実行時のOracle Walletの作成

SEC_PRINCIPAL_LOCATION構成パラメータまたはワークステーション・クライアントのSEC_PRINCIPAL_LOCATION環境変数がOracle Walletを指定しない場合、Tuxedoは従来のセキュリティ資格証明を探して、次のようにOracle Walletを作成しようとします。

  • 前のリリースと同じく、SEC_PRINCIPAL_LOCATIONはプロセスの秘密キーファイルを指定します。秘密キーファイルは、TLS接続のサーバー側のプロセスで必須です。または、相互認証が使用されるときは接続のクライアント側のプロセスで必須です。一方向TLS接続のクライアント側のプロセスでは省略可能です。SEC_PRINCIPAL_PASSVAR構成ファイル環境変数(またはワークステーション・クライアントのSEC_PRINCIPAL_PASSWORD環境変数)の値が、秘密キーを復号化するために使用されます。
  • プロセスの証明書チェーンは、SEC_PRINCIPAL_NAMEの値を入力として渡すプラグイン・フレームワークによって取得されます(デフォルトのプラグイン・フレームワーク実装では、これはLDAPを使用します)。証明書チェーンは、TLS接続のサーバー側のプロセスで必須です。または、相互認証が使用されるときは接続のクライアント側のプロセスで必須です。一方向TLS接続のクライアント側のプロセスでは省略可能です。
  • プロセスのための信頼性のある証明書は、プラグイン・フレームワークのcertificate_validationインタフェースのcaCertificateFileパラメータとして指定されるファイルに格納されますデフォルトのcaCertificateFileは$TUXDIR/udataobj/security/certs/trust_ca.cerです。信頼性のある証明書は、TLSサーバーとTLSクライアントに対して存在する必要があります。

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にコピーする必要があります。そうしないと、それが見つかりません。

親トピック: TLS暗号化の管理

2.14.9 TUXCREATEWALLET環境変数の使用

従来のセキュリティ資格証明のOracle Wallet形式への変換は、TUXCREATEWALLET環境変数の影響を受けます。これは、次のように設定されている可能性があります。

  • TUXCREATEWALLET=KEEP、TUXCREATEWALLET=YESまたはTUXCREATEWALLET設定解除: ウォレットが存在していないが、従来形式のセキュリティ資格証明が存在している場合、従来のセキュリティ資格証明をウォレットに変換します。これはデフォルトの動作です。ウォレットが作成されるディレクトリには700個の権限が格納されます。ewallet.p12ファイルには600個の権限が格納されます。ユーザーが既存のウォレットの読取りまたはウォレットの作成を行うには、適切な権限を持つ必要があります。ULOG_SSLINFO=yが設定されている場合は、次のメッセージが記録されます。 

    LIBTUX_CAT:6908: INFO: Security credentials for principal 
name have been converted to 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環境変数と同じく、ローカル言語で指定することもできます。

親トピック: TLS暗号化の管理

2.14.10 TLS接続の問題のデバッグ

親トピック: TLS暗号化の管理

2.14.10.1 NZトレース機能の有効化

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

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

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

2.14.10.3 Oracle Walletの内容の表示

様々なツールを使用して、Oracle Wallet (PKCS12ファイル)に関する情報を表示できます。

opensslは、一部のオペレーティング・システムではOSディストリビューションに含まれています。その他のオペレーティング・システムでは、ソースをダウンロードしてコンパイルできます。

次のopensslコマンドは、Oracle Walletの証明書と秘密キーを表示します。

openssl pkcs12 -in ewallet.p12

opensslでは、ウォレットを開くために使用するパスワードについてプロンプトが表示されます。(オプション-password pass:passwordを使用するとプロンプトが表示されませんが、このオプションを使用すると、同じマシンでpsコマンドを実行する別のユーザーがパスワードを見る可能性があります。)

opensslでは、秘密キーを端末に表示するとき、復号化された秘密キーを暗号化するためのパスワードについてもプロンプトが表示されます。オプション-nodesを使用すると、このプロンプトを表示せず、秘密キーを暗号化されていない形式で表示できます。

openss pkcs12の出力に含まれるすべての証明書は、別のファイルにコピーできます。また、次のコマンドを使用すると、証明書のフィールドが表示されます: 

openssl x509 -in certificatefile -text -noout

Oracle Databaseソフトウェアをインストールしているユーザーは、ウォレットに関する情報を表示するためにorapkiコマンドまたはowmグラフィカル・コマンドも使用できます。ウォレットの情報を表示するorapkiコマンドは次のとおりです。 

orapki wallet display -wallet wallet_location
2.14.10.4 NZエラー・コード情報の取得

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

$TUXDIR/locale/C/ORACLE.text

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

ノート:

2.15 公開キーセキュリティの管理

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

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

親トピック: セキュリティの管理

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

  • 実行できるセキュリティのレベルは、主にATMIアプリケーションの動作環境によって決まります。最も高いセキュリティのレベルを実現するには、秘密キーの情報を保護するハードウェア・デバイスをインストールします。
  • キーの有効期限とキーの更新手順についてのポリシーを決定します。認証局が発行する証明書の有効期限は、システムの操作に大きく影響する場合があります。したがって、有効期限の前に、更新した証明書を発行できるようにしておく必要があります。

親トピック: 公開キーセキュリティの管理

2.15.2 公開キーと秘密キーの組合せの割当て

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

  • 1つの公開キーをATMIアプリケーション全体に割り当てる
  • ATMIアプリケーション内の各マシンに対して公開キーと秘密キーの組合せを1つ割り当てる
  • ATMIアプリケーション内の各サーバーに対して公開キーと秘密キーの組合せを1つ割り当てる
  • ATMIアプリケーション内の各サービスに対して公開キーと秘密キーの組合せを1つ割り当てる
  • 各エンド・ユーザーに対して公開キーと秘密キーの組合せを1つ割り当てる

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

親トピック: 公開キーセキュリティの管理

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

管理者は、次の構成パラメータを使用して、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です。

親トピック: 公開キーセキュリティの管理

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

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

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

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

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

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

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

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

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

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.15.3.3.1 修飾子

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

2.15.3.3.2 例

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バッファは、前述のいずれかの方法で、システム側で拒否されます。
2.15.3.4 イベント・ブローカの署名ポリシーの適用

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

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

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

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

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

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

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

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

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

2.15.4 暗号化ポリシーの設定

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

パラメータ名 説明 設定
UBBCONFIGのENCRYPTION_REQUIRED (TM_MIBのTA_ENCRYPTION_REQUIRED) 受信側のプロセスで受け付けるメッセージ・バッファを、暗号化されたものだけに制限するかどうかを決定します。 Y (yes - 暗号化が必要)またはN (no - 暗号化は不要)を指定します。デフォルトはNです。

親トピック: 公開キーセキュリティの管理

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

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です。
  • グループ・レベル(GROUPSセクションまたはT_GROUPクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって通知されるアプリケーション・サービスを含め、特定のグループによって通知されるすべてのアプリケーション・サービスに適用されます。デフォルトはNです。
  • サービス・レベル(SERVICESセクションまたはT_SERVICEクラス)で設定すると、このパラメータは、ゲートウェイ・プロセスによって通知されるインスタンスを含め、ドメイン内で通知される特定サービスのすべてのインスタンスに適用されます。デフォルトはNです。

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

2.15.4.1.1 修飾子

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

2.15.4.1.2 例

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バッファは、前述のいずれかの方法で、システム側で拒否されます。
2.15.4.2 イベント・ブローカの暗号化ポリシーの適用

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

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

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

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

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

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

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

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

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

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

管理者は、次の構成パラメータを使用して、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 復号化キーの初期化例


復号化キーの初期化例の図

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

  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アプリケーションを停止するまで、オープンしたままの状態になります。

親トピック: 公開キーセキュリティの管理

2.15.5.1 プリンシパル名および復号化キーを指定する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"

2.15.6 障害のレポートと監査

この項では、デジタル署名とメッセージの暗号化で検出されたエラーがシステム側でどのように処理されるかを説明します。

親トピック: 公開キーセキュリティの管理

2.15.6.1 デジタル署名のエラー処理

メッセージの改ざんが検出された場合、つまり、コンポジット署名ステータスがTPSIGN_TAMPERED_MESSAGEまたはTPSIGN_TAMPERED_CERTの場合(「コンポジット署名ステータスの理解」を参照)、システム側では次のアクションが実行されます。

  • userlog(3c)メッセージを生成します(重大度はERROR (エラー))。
  • バッファを破棄し、プロセスで受信されなかったように扱います。

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

  • userlog(3c)メッセージを生成します(重大度はWARN (警告))。
  • バッファのコンポジット署名ステータスがTPSIGN_OKまたはTPSIGN_UNKNOWNでないかぎり、バッファを破棄し、プロセスで受信されなかったように扱います。

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

  • userlog(3c)メッセージを生成します(重大度はWARN (警告))。
  • バッファを破棄し、プロセスで受信されなかったように扱います。
2.15.6.2 暗号化のエラー処理

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

  • userlog(3c)メッセージを生成します(重大度はERROR (エラー))。
  • バッファを破棄し、プロセスで受信されなかったように扱います。

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

  • userlog(3c)メッセージを生成します(重大度はERROR (エラー))。
  • バッファを破棄し、プロセスで受信されなかったように扱います。

ノート:

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

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

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

親トピック: セキュリティの管理

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

管理者は、UBBCONFIG構成ファイルを編集するか、またはTM_MIBを変更することにより、ATMIアプリケーションのセキュリティ・レベルを指定できます。

親トピック: デフォルトの認証と認可の管理

2.16.1.1 構成ファイルを編集してセキュリティを指定する

UBBCONFIGファイルで、SECURITYパラメータに適切な値を設定します。 

SECURITY {NONE | APP_PW | USER_AUTH | ACL | MANDATORY_ACL}

デフォルトはNONEです。SECURITYにUSER_AUTH、ACL、またはMANDATORY_ACLを設定すると、システム側で提供される認証サーバーAUTHSVRが起動し、ユーザーごとの認証が行われます。

NONE以外の値を選択した場合は、MASTERサイトで動作する各ATMIアプリケーションに対して、ユニークなAPPDIR変数が設定されていることを確認します。セキュリティ機能を使用している場合、複数のATMIアプリケーションが同じアプリケーション・ディレクトリを共有することはできません。

2.16.1.2 TM_MIBを変更してセキュリティを指定する

TM_MIBを使用してセキュリティ・レベルを指定するには、T_DOMAINクラスのTA_SECURITY属性に値を割り当てなければなりません。ATMIアプリケーションが非アクティブの場合、管理者は、TA_SECURITYに対してUBBCONFIGで有効な任意の値を設定できます。このタスクを完了するには、管理インタフェースtpadmcall(3c)を実行します。

2.16.2 認証サーバーの構成

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

関連項目:

親トピック: デフォルトの認証と認可の管理

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

デフォルトの認証には、アプリケーション・パスワードというセキュリティ・レベルが用意されており、これは、構成ファイルの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アプリケーション・パスワードを配布します。

ノート:

親トピック: セキュリティの管理

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

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

USER_AUTHのセキュリティ・レベルを有効にするには、次のステップに従います:

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

これらのステップについては、次の2つの項で説明します。

親トピック: セキュリティの管理

2.18.1 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アプリケーション・パスワードを配布します。

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

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

デフォルトの認可システムで使用できるAUTHSVRとアクセス制御チェック機能では、tpusrというユーザー・ファイルが必要です。このファイルには、ATMIアプリケーションへの参加を許可されたクライアント・ユーザーのリストが含まれています。アプリケーション管理者は、tpusradd(1)、tpusrdel(1)、およびtpusrmod(1)の各コマンドを使用してtpusrを管理します。AUTHSVRサーバーは、tpusrファイルに格納されているクライアント・ユーザー情報を入力として受け取ります。AUTHSVRサーバーは、この情報を使用して、ATMIアプリケーションに参加しようとするクライアントを認証します。

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

図2-15 tpusrサンプル・エントリ


サンプル・エントリの図

AUTHSVRとアクセス制御チェック機能では、tpgrpというグループ・ファイルも必要です。このファイルには、ATMIアプリケーションへの参加を許可されたクライアント・ユーザーに関連付けられたグループのリストが含まれています。アプリケーション管理者は、tpusradd(1)、tpgrpdel(1)、およびtpgrpmod(1)の各コマンドを使用してtpgrpを管理します。

AUTHSVCは、認証されたクライアント・ユーザーにアプリケーション・キーを割り当てます。アプリケーション・キーには、USER_AUTH、ACLまたはMANDATORY_ACLのセキュリティ・レベルに対するユーザー識別子および関連するグループ識別子が含まれます。(アプリケーション・キーの詳細は、「アプリケーション・キー」を参照してください。)

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

図2-16 tpgrpサンプル・エントリ


tpgrpサンプル・エントリの図

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

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

2.18.2.1 システムのセキュリティ・データ・ファイルを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により、変換したデータがファイルに追加されます。ただし、重複するグループ情報が追加されることはありません。

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

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

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

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

実行するコマンド 目的 エントリが格納されているファイル名
tpusradd(1) 追加 tpusr
tpusrmod(1) 変更
tpusrdel(1) 削除
tpgrpadd(1) 追加 tpgrp
tpgrpmod(1) 変更
tpgrpdel(1) 削除

これらのコマンドを実行するには、次のステップに従います:

  1. 非アクティブなATMIアプリケーションの場合、アプリケーションのMASTERマシンで作業していることを確認します。アクティブなATMIアプリケーションの場合は、構成内のどのマシンからでも作業できます。
  2. コマンドの実行方法については、『Oracle Tuxedoコマンド・リファレンス』で各コマンドのエントリを参照してください。
2.18.2.2.2 ACL_MIBを使用してユーザーおよびグループのエントリを変更する

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

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

ノート:

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

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

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

  • システム管理を簡素化できます。新しいサービスへのアクセス権を付与する場合、1つのグループに対してアクセス権を付与する方が、個別の複数のユーザーに付与するより簡単です。
  • パフォーマンスを高めることができます。エンティティを呼び出すたびにアクセス・パーミッションをチェックする必要があるため、パーミッションはすばやく解決できなければなりません。グループの数はユーザーの数より少ないため、権限を持つユーザーのリストを検索するよりも、権限を持つグループのリストを検索する方が高速です。

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

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

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

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

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

親トピック: セキュリティの管理

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

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

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

ACLのセキュリティ・レベルを有効にするには、次のステップに従います:

  1. UBBCONFIGファイルを設定します。
  2. ACLファイルを設定します。

これらのステップについては、次の2つの項で説明します。

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

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

  3. tmloadcf(1)を実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。
  4. 電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。
2.19.1.2 ACLファイルの設定

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

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

図2-17 tpaclサンプル・エントリ


tpaclサンプル・エントリの図

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

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

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

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

実行するコマンド 目的
tpacladd(1) エントリの追加
tpaclmod(1) エントリの変更
tpacldel(1) エントリの削除

これらのコマンドを実行するには、次のステップに従います:

  1. 非アクティブなATMIアプリケーションの場合、アプリケーションのMASTERマシンで作業していることを確認します。アクティブなATMIアプリケーションの場合は、構成内のどのマシンからでも作業できます。
  2. コマンドの実行方法については、『Oracle Tuxedoコマンド・リファレンス』で各コマンドのエントリを参照してください。

親トピック: ACLファイルの設定

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

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

親トピック: ACLファイルの設定

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

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

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

MANDATORY_ACLのセキュリティ・レベルを有効にするには、次のステップに従います:

  1. UBBCONFIGファイルを設定します。
  2. ACLファイルを設定します。

これらのステップについては、次の2つの項で説明します。

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

2.19.2.1 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. 電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してATMIアプリケーション・パスワードを配布します。
2.19.2.2 ACLファイルの設定

2.19.3 一般的な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. 認可キャッシュの設定

これらのステップについては、次の項で説明します。

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

2.19.3.1 UBBCONFIGファイルの設定
  1. テキスト・エディタでUBBCONFIGを開きます。
  2. RESOURCESセクションで次のように設定します。
    1. SECURITYパラメータをUSER_AUTH、ACLまたはMANDATORY_ACLのいずれかの値に設定します。
    2. OPTIONSパラメータをEXT_AAに設定します。
    3. 次の内の1つを実行します。
      • SECURITYパラメータがACLまたはMANDATORY_ACLAUTHSVCに設定された場合は、AUTHSVCを..AUTHSVC (XAUTHSVRサーバーによって通知されているサービス名)に設定します。
      • SECURITYパラメータがUSER_AUTHに設定された場合、AUTHSVCをAUTHSVC (XAUTHSVRサーバーによって通知されているサービス名)に設定します。
  3. SERVERSセクションでXAUTHSVRを設定します。
    * RESOURCES
           SECURITY     
           ACL AUTHSVC ..AUTHSVC OPTIONS          
               EXT_AA
               *SERVERS
               XAUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y
2.19.3.2 XAUTHSVRサーバー構成ファイルの設定

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

次の表で、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"です。
2.19.3.3 LDAPリポジトリの設定

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

  • inetOrgPerson: このオブジェクト・クラスは、ユーザーを表すエントリを保持します。定義は、属性"uid"の長さが30文字以内に制限されることを除き、RFC 4519および2798標準に従います。各Oracle Tuxedoユーザーはこのクラスのエントリとして保存されます。ユーザーIDとユーザー・パスワードを含むこの情報は、ユーザーレベル認証で使用されます。
  • groupOfUniqueNames: このオブジェクト・クラスは、名前付きオブジェクトのセットを表すエントリを保持します。セットの目的や保守に関連する情報も含まれます。この定義はRFC 4519標準に従います。このクラスにより、特定の種類の権限を付与されるユーザーのリストがグループ分けされます。グループはネストできます。親グループに付与される権限は子グループにも適用されます。
  • Orcljaznpermission: このオブジェクト・クラスは、次の表に示す属性で構成されるtuxedo権限オブジェクトを保持します。このオブジェクトは2つの部分で構成されます。1つは権限です。これは、リソース・タイプ、ターゲット・リソース、ターゲット・リソース上のアクションを示します。もう1つは、この権限が付与される、割当て済のグループまたはユーザーです。

次の表で、orcljaznpermissionクラスの属性について説明します。

表2-4 orcljaznpermissionクラスの属性

属性 データ型 制約 説明
Cn String: 単一値、一意、必須 権限名
Displayname String: String: 表示名
Description String: String: 説明
OrclJpsResourceTypeName String: 単一値 保護するリソースのタイプ名。Tuxedoサービスを定義するときは、この属性を" SERVICE"に指定します。
Orcljaznpermissiontarget String: 単一値 保護するリソースの名前。Tuxedoサービスを定義するときは、この属性をサービス名として指定します。
Orcljaznpermissionactions String: 単一値 割り当てられたアクションをカンマで区切ったリスト。Tuxedoサービスを定義するときは、この属性を"EXECUTE"に指定します。
2.19.3.4 認可キャッシュの設定

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、MAXTMATZPRIVILEGEMAX値は1000と仮定します。
使用メモリー・サイズの計算式([リソース・エントリの最大数] * [リソース・エントリのサイズ] + [権限エントリの最大数]*[権限エントリのサイズ])に従うと、この場合の結果は次のようになります。
(10*148 + 1000*50)= 51480 (51 KB)

ノート:

2.19.4 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インストレーション・ガイドを参照してください。

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

2.20 Kerberos認証プラグインの使用

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

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

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

親トピック: セキュリティの管理

2.21 Kerberosプラグイン

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

親トピック: セキュリティの管理

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

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

  • Windows 2000/2003サーバーに同梱のMicrosoft Kerberos
  • HPで提供されているHP-UX(PA-RISC)のKerberos Vシステム
  • Sun Microsystemsで提供されているSolaris 9 (SPARC)のKerberos Vシステム

親トピック: Kerberosプラグイン

2.21.2 Kerberosプラグインの機能

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

  • Tuxedoネイティブ・クライアントとサーバーの間の認証
  • Tuxedo ACLセキュリティ・メカニズムの完全なサポート

    ノート:

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

親トピック: Kerberosプラグイン

2.22 Kerberosプラグインの事前構成

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

  • サポートされているシステムが適切なKerberos設定で実行されていること
  • ユーザー/サービス・アカウントが適切に設定されていること
  • Kerberos認証サーバー・キー表が、UNIXで適切に作成されていること
  • UNIXとWindowsの間のKerberosの相互運用性が適切に設定されており、異種(UNIXとWindowsが混在している)環境で必要な場合は動作検証されていること

親トピック: セキュリティの管理

2.23 Kerberosプラグインの構成

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

  1. Kerberosプラグインの構成
  2. KAUTHSVRの構成
  3. Tuxedoネイティブ・クライアントの構成

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

親トピック: セキュリティの管理

2.23.1 Kerberosプラグインの構成

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

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

リスト 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

リスト 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にアクセスします。
  • Windows Tuxedoクライアントは、必ず完全なKerberosレルム名を使用してKAUTHSVRにアクセスします。

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

親トピック: Kerberosプラグインの構成

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

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

リスト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

ノート:

上のリストでは、libtux.soが例として使用されます。ファイル名libtuxにプラットフォーム固有の動的ライブラリの拡張子を付ける必要があります。

2.23.2 KAUTHSVRの構成

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

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

リスト UNIX UBBCONFIG KAUTHSVR構成

*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形式を使用する必要があります。

リスト Windows UBBCONFIG KAUTHSVR構成

*RESOURCES 
          IPCKEY 66666     
          MASTER SITE1 
          MODEL MP 
          
         SECURITY MANDATORY_ACL 
         
         *SERVERS 

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

ノート:

-pオプションは、KAUTHSVRプリンシパル名を示します。

Windowsプラットフォームでは、-kオプションのかわりに次の2つの引数を使用する必要があります。

Windowsプラットフォームでは、-kオプションのかわりに次の2つの引数を使用する必要があります。

  • SEC_PRINCIPAL_NAMEは、(-pオプションで示した)サーバー・プリンシパル名ではなくKAUTHSVRを表します。
  • SEC_PRINCIPAL_PASSVARは内部のパスワード変数です。これは、tmloadcfがTUXCONFIGファイルを作成する際に必要な実際のパスワードではありません。tmloadcfパスワード入力は、WindowsドメインのKAUTHSVRアカウント・パスワードと同じものでなくてはなりません。

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

親トピック: Kerberosプラグインの構成

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

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

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

親トピック: Kerberosプラグインの構成

2.23.4 制限事項

  • 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)

親トピック: Kerberosプラグインの構成

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

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

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

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

親トピック: セキュリティの管理

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

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

親トピック: セキュリティの管理

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

Tuxedo Cert-C PKI暗号化プラグインを使用するには、必ず次のシステム要件に従う必要があります:

  • 構成されたLDAPサーバーにアクセスできること
  • LDAPに格納されたユーザー証明書がcn=user nameという形式で入力されていること

親トピック: セキュリティの管理

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

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

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

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

親トピック: セキュリティの管理

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

このインタフェース・グループは、ユーザー証明書が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プラグインに通知します。

親トピック: Cert-C PKI暗号化プラグインの構成

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

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

リスト 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ファイルを変更する必要もあります。
    リストに、フィルタの例を示します。

リスト フィルタの例

"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"

2.27.2 キー管理の構成

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

親トピック: Cert-C PKI暗号化プラグインの構成

2.27.2.1 decPassword

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

decPassword="abc123"

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

ノート:

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

親トピック: キー管理の構成

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

親トピック: キー管理の構成

2.27.3 証明書解析の構成

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

ノート:

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

親トピック: Cert-C PKI暗号化プラグインの構成

2.27.4 証明書検証の構成

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

親トピック: Cert-C PKI暗号化プラグインの構成

2.27.4.1 caCertificateFile

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

ノート:

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

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

親トピック: 証明書検証の構成

2.27.4.2 crlFile

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

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

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

親トピック: 証明書検証の構成

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

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

ノート:

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

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

    Solaris: libcertctux.so.71

    HP-UX: libcertctux.sl
  • ファイルURLをUNIX形式に変更します。

リスト WindowsでTuxedoレジストリ・データベースを変更するためのサンプル・コマンド

REM **********************************************************
         REM ** Modify Validation Interface **
         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 ** Modify Lookup Interface **
         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 ** Modify Key Management Interface **
         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 ** Modify Certificate Parsing Interfaces **
         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

親トピック: Cert-C PKI暗号化プラグインの構成

2.27.6 制限事項

  • 識別名の"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)

親トピック: Cert-C PKI暗号化プラグインの構成