|
|
| 注意: | Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。すべてのOracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト・リファレンスとコード・サンプルは、サード・パーティ製のJava ORBライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。 |
| 注意: | サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートやドキュメントは提供していません。 |
リンク・レベルの暗号化(LLE)は、ネットワーク・リンク上で送受信されるメッセージのデータ機密性を保護します。LLEの目的は、Oracle TuxedoシステムのメッセージやCORBAアプリケーションが生成したメッセージの内容を、ネットワーク上の侵入者に知られないようにすることです。また、対称鍵による暗号化技術であるRC4を使用します。RC4では、暗号化と復号化の際に同じ鍵を使用します。
LLEを使用する場合、Oracle Tuxedoシステムは、データを暗号化してからネットワーク・リンク上に送信し、データがネットワーク・リンクを離れると復号化します。システムは、データが通過するすべてのリンクで、この暗号化/復号化プロセスを繰り返します。したがって、LLEはポイント・ツー・ポイント機能と呼ばれます。
LLEを使用すると、CORBAアプリケーション内のマシンとドメイン間の通信を暗号化できます。
| 注意: | LLEは、リモートCORBAクライアント・アプリケーションとIIOPリスナー/ハンドラ間の接続の保護には使用できません。 |
LLEセキュリティには、0ビット(暗号化なし)、56ビット(国際版)、128ビット(米国およびカナダ版)の3つのレベルがあります。国際版のLLEでは、0ビットと56ビットの暗号化が可能です。米国およびカナダ版のLLEでは、0ビット、56ビット、および128ビットの暗号化が可能です。
図3-1に、これらの手順を示します。
ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階の手順で確認されます。
2つのプロセスのうち、どちらかが起動すると、Oracle Tuxedoシステムは、(1) lic.txtファイルのLLE情報を参照して、インストール済のLLEのバージョンのビット暗号化機能をチェックし、(2)両方のプロセスの構成ファイルで指定されている、特定の種類のリンクでのLLEのmin-max値をチェックします。続いて、Oracle Tuxedoシステムは次の処理を実行します。
min-max値が、インストール済のLLEのバージョンと対応する場合、ローカル・ソフトウェアは、この値をプロセスのmin-max値として割り当てます。min-max値が、インストール済のLLEのバージョンと対応しない場合、ローカル・ソフトウェアからは実行時エラーが返されます。たとえば、国際版のLLEがインストールされているときに、min-max値が(0, 128)である場合です。この時点では、リンク・レベルの暗号化は不可能です。min-max値が指定されていない場合、ローカル・ソフトウェアは、最小値として0を割り当て、最大値としてインストール済のLLEのバージョンに対して可能な最高ビットの暗号化レートを割り当てます。つまり、米国およびカナダ版のLLEでは(0, 128)を割り当てます。 2つのプロセスのmin-max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。
表3-1は、2つのプロセス間で可能なmin-max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスのmin-max値を示しています。左側の列は、もう一方のプロセスのmin-max値を示しています。
ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、LLEを使用しないアプリケーションでは30秒、LLEを使用するアプリケーションでは60秒に制限されています。この60秒には、暗号化されたリンクを調整する時間も含まれます。ただし、LLEが構成されている場合は、UBBCONFIGファイルのMAXINITTIMEパラメータでワークステーション・リスナー(WSL)のサーバーの値を変更するか、WS_MIB(5)にあるT_WSLクラスのTA_MAXINITTIME属性の値を変更することによって、制限を変更できます。
CORBAアプリケーションでLLEを使用するには、LLEを有効にするライセンスをインストールする必要があります。ライセンスのインストール方法については、『Oracle Tuxedoシステムのインストール』を参照してください。
LLEの実装は管理タスクの1つです。各CORBAアプリケーションのシステム管理者は、暗号化のレベルを制御するmin-max値をUBBCONFIGファイルで設定します。2つのCORBAアプリケーションは、通信を確立すると、メッセージのやり取りに使用する暗号化のレベルをネゴシエーションします。ネゴシエーションされた暗号化レベルは、ネットワーク接続が確立されている間は有効です。
CORBAセキュリティ環境では、PKI (Public Key Infrastructure)を全面的にデプロイする準備が整っていない既存のCORBAアプリケーションおよび新しいCORBAアプリケーションに対して認証機能を提供するためのパスワード・メカニズムをサポートしています。パスワードによる認証を使用すると、CORBAオブジェクトを呼び出すアプリケーションは、定義されているユーザー名およびパスワードを提示して、Oracle Tuxedoドメインに対して自身を認証します。
パスワードによる認証を使用する場合、クライアント・アプリケーションでTobj::PrincipalAuthenticator::logon()メソッドを使用する方法と、SecurityLevel2::PrincipalAuthenticator::authenticate()メソッドを使用する方法があります。
パスワードによる認証を使用する場合、SSLプロトコルによって、アプリケーション間の通信の機密性と整合性を保護できます。詳細は、「SSLプロトコル」を参照してください。
図3-2に、これらの手順を示します。
パスワードによる認証をCORBAアプリケーションに定義するには、管理手順とプログラミング手順を実行する必要があります。表3-2と表3-3に、パスワード認証の管理手順とプログラミング手順をそれぞれ示します。パスワードによる認証の管理手順の詳細は、「認証の構成」を参照してください。プログラミング手順の詳細は、「セキュリティを実装するCORBAアプリケーション」を参照してください。
Oracle Tuxedo製品では、業界標準のSSLプロトコルを使用して、クライアント・アプリケーションとサーバー・アプリケーション間で安全な通信を確立します。SSLプロトコルを使用する場合、プリンシパルはデジタル証明書を使用して、自身のIDをピアに対して証明します。
CORBAセキュリティ環境のSSLプロトコルのデフォルト動作では、IIOPリスナー/ハンドラが自身のIDを、デジタル証明書を使用してSSL接続を開始したプリンシパルに対して証明します。デジタル証明書は、各デジタル証明書が改ざんされていないこと、また有効期限が切れていないことを確認されます。一連の処理でデジタル証明書に問題があった場合、SSL接続は終了します。また、デジタル証明書の発行者は信頼性のある認証局のリストと照合され、IIOPリスナー/ハンドラから受信したデジタル証明書がOracle Tuxedoドメインの信頼する認証局が署名したものであるかどうか確認されます。
LLEと同じく、SSLプロトコルをパスワードによる認証で使用すると、クライアント・アプリケーションとOracle Tuxedoドメイン間の通信の機密性と整合性を保護できます。SSLプロトコルをパスワードによる認証で使用する場合、tmloadcfコマンドを入力したときにSEC_PRINCIPAL_NAMEパラメータで定義したIIOPリスナー/ハンドラのパスワードの入力を求められます。
図3-3に、SSLプロトコルのしくみを示します。
CORBAアプリケーションでSSLプロトコルを使用するには、SSLプロトコルおよびPKIを有効にするライセンスをインストールする必要があります。セキュリティ機能のライセンスのインストール方法については、『Oracle Tuxedoシステムのインストール』を参照してください。
SSLプロトコルの実装は柔軟性が高いので、ほとんどの公開鍵インフラストラクチャに対応します。Oracle Tuxedo製品では、デジタル証明書をLDAP対応のディレクトリに保存する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、CORBAアプリケーションで使用するデジタル証明書および秘密鍵の取得先の認証局を選択する必要があります。LDAP対応のディレクトリ・サービスおよび認証局を準備してからでないと、SSLプロトコルをCORBAアプリケーションで使用できません。
CORBAアプリケーションでSSLプロトコルを使用するのは、主に管理プロセスです。表3-4は、SSLプロトコルを使用できるようにインフラストラクチャを設定し、SSLプロトコルに合せてIIOPリスナー/ハンドラを構成するための管理手順の一覧です。管理手順の詳細は、「公開鍵によるセキュリティ機能の管理」および「SSLプロトコルの構成」を参照してください。
管理手順を実行したら、パスワードによる認証と証明書による認証のどちらもCORBAアプリケーションで使用できます。詳細は、「セキュリティを実装するCORBAアプリケーション」を参照してください。
| 注意: | Oracle CORBA C++ ORBをサーバー・アプリケーションとして使用している場合、ORBでもSSLプロトコルを使用するように構成できます。詳細は、「SSLプロトコルの構成」を参照してください。 |
SSLプロトコルをパスワードによる認証で使用する場合、UBBCONFIGファイルのSECURITYパラメータを目的の認証レベルに設定し、必要であれば、認証サーバー(AUTHSRV)を構成します。パスワード認証の管理手順については、「パスワードによる認証」を参照してください。
図3-4に、SSLプロトコルを使用する場合のCORBAアプリケーションの構成を示します。
証明書による認証では、SSL接続の両端がそれぞれのIDを互いに証明する必要があります。CORBAセキュリティ環境では、IIOPリスナー/ハンドラは自身のデジタル証明書を、SSL接続を開始したプリンシパルに対して提示します。イニシエータは、IIOPリスナー/ハンドラが使用する一連のデジタル証明書を提示して、イニシエータのIDを証明します。
一連のデジタル証明書の検証に成功すると、IIOPリスナー/ハンドラはデジタル証明書のサブジェクトから識別名の値を取り出します。CORBAセキュリティ環境では、サブジェクトの識別名の電子メール・アドレス要素をプリンシパルのIDとして使用します。IIOPリスナー/ハンドラは、プリンシパルのかわりにプリンシパルのIDを使用して、開始元アプリケーションとOracle Tuxedoドメイン間のセキュリティ・コンテキストを確立します。
プリンシパルが認証されたら、リクエストを開始したプリンシパルとIIOPリスナー/ハンドラは、双方がサポートしている暗号化の種類とレベルを表す暗号スイートについて合意します。また、暗号鍵についても合意し、以降のすべてのメッセージについて同時に暗号化を開始します。
図3-5に、証明書による認証の概念を示します。
一般に、X509 V3 CA証明書には、認証局(CA)からのもの、かつクリティカルな拡張(IETF RFC 2459を参照)として識別されている基本制約拡張が含まれている必要があります。V3 CA証明書は、CA以外の証明書が中間CA証明書を偽装するのを防ぎます。
http://www.ietf.org/rfc/rfc2459.txt
| 注意: | このデフォルトの動作では、X.509 V1およびV2証明書に対して基本制約はチェックされません。これらのバージョンのX.509証明書は、証明書拡張をサポートしていません。 |
顧客のアプリケーションでの問題を回避するために実行される強制レベルを制御するために、あるメカニズムが用意されています。
このメカニズムを使用するには、環境変数TUX_SSL_ENFORCECONSTRAINTSの値を設定します。強制レベルは次のとおりです。
| 注意: | 12.1.1より前のバージョンのTuxedoでは、値に0を指定して、基本制約の強制全体を無効にすることもできました。このオプションは、基本制約がX.509規格のまだ新しい機能であった頃に、古い証明書との互換性を提供するために用意されていました。もはや必要ないため、Tuxedo 12.1.1以降ではTUX_SSL_ENFORCECONSTRAINTS=0は指定できません。 |
| 注意: | SecurityLevel2::Current::authenticate()メソッドを使用しても、ブートストラップ処理のセキュリティを確保し、証明書による認証を使用するように指定できます。 |
SecurityLevel2::PrincipalAuthenticator::authenticate()メソッドの結果として、セキュリティ・コンテキストが確立されます。
IIOPリスナー/ハンドラは、認証プロセスの一部として、アプリケーションのデジタル証明書を受信して検証します。
Credentialsオブジェクトを作成します。プリンシパルのCredentialsオブジェクトは、現在の実行スレッドのセキュリティ・コンテキストを表します。CORBAアプリケーションで証明書による認証を使用するには、SSLプロトコルおよびPKIを有効にするライセンスをインストールする必要があります。ライセンスのインストール方法については、『Oracle Tuxedoシステムのインストール』を参照してください。
証明書による認証をCORBAアプリケーションで使用するには、管理手順とプログラミング手順を実行する必要があります。表3-5と表3-6に、証明書による認証の管理手順とプログラミング手順をそれぞれ示します。管理手順の詳細は、「公開鍵によるセキュリティ機能の管理」および「SSLプロトコルの構成」を参照してください。
図3-7に、証明書による認証を使用する場合のCORBAアプリケーションの構成を示します。
表3-6は、CORBAアプリケーションで証明書による認証を使用するためのプログラミング手順をまとめたものです。詳細は、「セキュリティを実装するCORBAアプリケーション」を参照してください。
BootstrapオブジェクトのURLアドレス形式(
corbalocまたはcorbalocs)を使用するアプリケーション・コードを記述します。IIOPリスナー/ハンドラの証明書の識別名のCommonNameがURLアドレス形式で指定されたホスト名と正確に一致している必要があります。URLアドレス形式の詳細は、「ブートストラップ処理メカニズムの使用」を参照してください。
CORBA INSブートストラップ処理メカニズムを使用しても、Oracle TuxedoドメインのPrincipalAuthenticatorオブジェクトへのリファレンスを取得できます。CORBA INSの詳細は、『CORBAプログラミング・リファレンス』を参照してください。
|
|
Oracle Tuxedo製品では、認証プラグインをCORBAアプリケーションに統合することができます。Oracle Tuxedo製品は、共有シークレット・パスワード、ワンタイム・パスワード、チャレンジ・レスポンス、Kerberosなどの認証技術を使用して、様々な認証プラグインに対応できます。認証インタフェースは、必要に応じてGSSAPI (Generic Security Service Application Programming Interface)に基づいており、認証プラグインがGSSAPIに合せて記述されていることを想定しています。
認証プラグインを使用する場合、Oracle Tuxedoシステムのレジストリで認証プラグインを構成する必要があります。レジストリの詳細は、「セキュリティ・プラグインの構成」を参照してください。
認証プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
認可の機能により、管理者はCORBAアプリケーションへのアクセスを制御できます。つまり、管理者は、認可機能を使用して、CORBAアプリケーションのリソースまたはサービスに対するアクセス権をプリンシパル(認証されたユーザー)に許可するかどうかを決定します。
CORBAセキュリティ環境では、認可プラグインを統合できます。認可は、認証トークンで提示されたユーザーIDに基づいて決定されます。認証トークンは認証プロセスで生成されるので、認証プラグインと認可プラグインとの間で調整する必要があります。
認証プラグインを使用する場合、Oracle Tuxedoシステムのレジストリで認証プラグインを構成する必要があります。レジストリの詳細は、「セキュリティ・プラグインの構成」を参照してください。
認可プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
監査とは、操作リクエストとその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、CORBAのセキュリティ・ポリシーに違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。
監査機能の現在の実装では、ログオンの失敗、偽装の失敗、および許可されなかった操作をULOGファイルに記録できます。操作が許可されなかった場合、どの操作のパラメータの順序もデータ型もわからないので、操作のパラメータ値は提供されません。ログオンおよび偽装に関する監査のエントリには、認証を受けようとしたプリンシパルのIDが含まれます。ULOGファイルの設定については、『Oracle Tuxedoアプリケーションの設定』を参照してください。
監査プラグインを使用すると、CORBAアプリケーションの監査機能を拡張できます。Oracle Tuxedoシステムは、定義済の実行ポイントで監査プラグインを呼び出します。通常、実行ポイントは、操作を試行する前、セキュリティ違反につながる現象を検出した場合、または操作が成功した場合です。監査情報を収集、処理、保護、および配布するためのアクションは、監査プラグインの機能によって異なります。監査情報を収集する場合はパフォーマンスへの影響を十分に考慮する必要があります。特に、成功した操作の監査には、大きなコストが発生することがあります。
監査に関する一部の決定は、監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
監査リクエストの目的は、イベントを記録することです。各監査プラグインは、success(監査が成功し、イベントが記録される)またはfailure(監査は失敗し、イベントは記録されない)のどちらかのレスポンスを返します。監査プラグインは、操作の実行前と実行後にそれぞれ一度呼び出されます。
CORBAアプリケーションで監査プラグインの複数の実装を使用することができます。複数の認可プラグインを使用すると、操作前および操作後の監査操作が複数実行されます。
複数の監査プラグインを使用する場合、すべてのプラグインは、1つのマスター監査プラグインの下に配置されます。それぞれの従属認証プラグインは、SUCCESSまたはFAILUREを返します。いずれかのプラグインが操作に失敗すると、マスター・プラグインが出力をFAILUREと決定します。その他のエラーもFAILUREとみなされます。それ以外の場合、SUCCESSが出力されます。
さらに、Oracle Tuxedoシステムのプロセスは、セキュリティ違反につながる現象を検出すると、監査プラグインを呼び出す場合があります。たとえば、操作前または操作後の認可のチェックが失敗したり、セキュリティに対する攻撃が検出された場合などです。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを示すレスポンスを返します。
Oracle Tuxedo製品に組み込まれている監査機能を使用する場合と、監査プラグインを使用する場合では、監査のプロセスが多少異なります。デフォルトの監査機能では、操作前の監査をサポートしていません。したがって、デフォルトの監査機能が、操作前の監査を行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。
デフォルトの監査プラグイン以外の監査プラグインを使用する場合、Oracle Tuxedoシステムのレジストリでその監査プラグインを構成する必要があります。レジストリの詳細は、「セキュリティ・プラグインの構成」を参照してください。
監査プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
Oracle Tuxedo製品には、CORBAアプリケーションでデジタル証明書を使用するために必要なSSLプロトコルとインフラストラクチャを含むPKI環境が用意されています。ただし、PKIインタフェースを使用して、カスタム・メッセージ・ベースのデジタル署名およびメッセージ・ベースの暗号化機能をCORBAアプリケーションに提供するPKIプラグインを統合できます。表3-7に、これらの手順を示します。
PKIインタフェースは、次のアルゴリズムをサポートしています。
PKIプラグインを使用する場合、Oracle TuxedoシステムのレジストリでPKIプラグインを構成する必要があります。レジストリの詳細は、「セキュリティ・プラグインの構成」を参照してください。
PKIプラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
ここでは、CORBAのセキュリティ機能についてよく寄せられる質問をいくつか取り上げて回答します。
いいえ、必要ありません。CORBAアプリケーションで以前のバージョンのWebLogic Enterpriseのセキュリティ・インタフェースを使用している場合、CORBAアプリケーションを変更する必要はありません。現在のセキュリティ・スキームをそのまま使用しても、既存のCORBAアプリケーションは8.0以降のOracle TuxedoでビルドしたCORBAアプリケーションと協調動作します。
たとえば、CORBAアプリケーションが、接続したすべてのクライアント・アプリケーションに一般的な情報を提供する一連のサーバーで構成されている場合、セキュリティ・スキームを強化する必要はまったくありません。CORBAアプリケーションが、スニッファを検出できるだけのセキュリティ機能を持つ内部ネットワークのクライアント・アプリケーションに情報を提供する一連のサーバー・アプリケーションで構成されている場合、新たなセキュリティ機能を実装する必要はありません。
答えは「はい」です。SSLプロトコルを既存のCORBAアプリケーションで使用すると、さらにセキュリティ機能を強化することができます。たとえば、株価を特定のクライアント・アプリケーションに提供するCORBAサーバー・アプリケーションでは、SSLプロトコルを使用すると、クライアント・アプリケーションが正しいCORBAサーバー・アプリケーションに接続しており、不正なデータを持つ偽のCORBAサーバー・アプリケーションにルーティングされていないことを保証できます。クライアント・アプリケーションを認証する証明資料としては、ユーザー名とパスワードで十分です。しかし、SSLプロトコルを使用することで、メッセージのリクエスト/応答情報をさらに高いレベルのセキュリティ機能で保護できます。
SSLプロトコルを使用すると、CORBAアプリケーションに次の利点があります。
CORBAアプリケーションでSSLプロトコルを使用するには、デジタル証明書を使用するインフラストラクチャを設定し、SSLプロトコルを使用するようにISLサーバー・プロセスのコマンドライン・オプションを変更した上で、IIOPリスナー/ハンドラの安全な通信用のポートを構成します。既存のCORBAアプリケーションがパスワードによる認証を使用する場合、SSLプロトコルでそのコードを使用できます。CORBA C++クライアント・アプリケーションが、Bootstrapオブジェクトへの初期参照を解決して認証を実行する際に、InvalidDomain例外を捕捉しない場合は、この例外を処理するコードを記述します。詳細は、「PKIプラグイン」を参照してください。
既存のCORBAアプリケーションを移行して、CORBAアプリケーションと市販のWebブラウザ間でインターネット接続を使用するときです。たとえば、CORBAアプリケーションのユーザーがインターネット上で買い物をするとします。ユーザーに対して次の点を保証する必要があります。
こうした場合、SSLプロトコルおよび証明書による認証を使用すると、CORBAアプリケーションで最高レベルの保護機能が提供されます。SSLプロトコルによる利点以外にも、証明書による認証を使用すると、CORBAアプリケーションに次の利点があります。
詳細は、「PKIプラグイン」を参照してください。
  
|
