|
|
| 注意 : | 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 プロトコルの実装は柔軟性が高いので、ほとんどの PKI に対応します。Oracle Tuxedo 製品では、デジタル証明書を LDAP 対応のディレクトリに保存する必要があります。LDAP 対応であれば、どのディレクトリ サービスでもかまいません。また、CORBA アプリケーションで使用するデジタル証明書およびプライベート キーの取得先の認証局を選択する必要があります。LDAP 対応のディレクトリ サービスおよび認証局を準備してからでないと、SSL プロトコルを CORBA アプリケーションで使用できません。
CORBA アプリケーションで SSL プロトコルを使用するための準備は、主に管理プロセスです。表 3-5 は、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 の値を設定します。強制レベルは以下のとおりです。
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 アプリケーション」を参照してください。
corbaloc または corbalocs) を使用するアプリケーション コードを記述します。IIOP リスナ/ハンドラの証明書の識別名の CommonName が URL アドレス形式で指定されたホスト名と正確に一致している必要があります。URL アドレス形式の詳細については、「ブートストラップ処理メカニズムの使用」を参照してください。
|
|
Oracle Tuxedo 製品では、認証プラグインを CORBA アプリケーションに統合することができます。Oracle Tuxedo 製品は、共有シークレット パスワード、ワンタイム パスワード、CHALLENGE 応答、Kerberos などの認証技術を使用して、さまざまな認証プラグインに対応できます。認証インタフェースは、必要に応じて GSSAPI (Generic Security Service Application Programming Interface) に基づいており、認証プラグインが GSSAPI に合わせて記述されていることを想定しています。
認証プラグインを使用する場合、Oracle Tuxedo システムのレジストリで認証プラグインをコンフィグレーションする必要があります。レジストリの詳細については、「セキュリティ プラグインのコンフィグレーション」を参照してください。
認証プラグインの詳細 (インストール手順およびコンフィグレーション手順を含む) については、Oracle 社の営業担当者にお問い合わせください。
認可の機能により、管理者は CORBA アプリケーションへのアクセスを制御できます。つまり、管理者は、認可機能を使用して、CORBA アプリケーションのリソースまたはサービスに対するアクセス権をプリンシパル (認証されたユーザ) に許可するかどうかを決定します。
CORBA セキュリティ環境では、認可プラグインを統合できます。認可は、認証トークンで提示されたユーザ ID に基づいて決定されます。認証トークンは認証プロセスで生成されるので、認証プラグインと認可プラグインとの間で調整する必要があります。
認可プラグインを使用する場合、Oracle Tuxedo システムのレジストリで認可プラグインをコンフィグレーションする必要があります。レジストリの詳細については、「セキュリティ プラグインのコンフィグレーション」を参照してください。
認可プラグインの詳細 (インストール手順およびコンフィグレーション手順を含む) については、Oracle 社の営業担当者にお問い合わせください。
監査とは、操作要求とその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、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 社の営業担当者にお問い合わせください。
Oracle Tuxedo 製品には、CORBA アプリケーションでデジタル証明書を使用するために必要な SSL プロトコルとインフラストラクチャを含む PKI 環境が用意されています。ただし、PKI インタフェースを使用して、カスタム メッセージ ベースのデジタル署名およびメッセージ ベースの暗号化機能を CORBA アプリケーションに提供する PKI プラグインを統合できます。表 3-7 に、これらの手順を示します。
PKI インタフェースは、次のアルゴリズムをサポートしています。
PKI プラグインを使用する場合、Oracle Tuxedo システムのレジストリで PKI プラグインをコンフィグレーションする必要があります。レジストリの詳細については、「セキュリティ プラグインのコンフィグレーション」を参照してください。
PKI プラグインの詳細 (インストール手順およびコンフィグレーション手順を含む) については、Oracle 社の営業担当者にお問い合わせください。
ここでは、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 プラグイン」を参照してください。
  
|
