|
注意:
|
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ビットの暗号化が可能です。
|
1.
|
システム管理者が、暗号化レベルを制御するためにLLEを使用するプロセスのパラメータを設定します。 |
|
•
|
最初の構成パラメータは、プロセスが受け入れる暗号化の最低レベルです。これは、0、56、128のいずれかのキー長で指定します。 |
|
•
|
2番目の構成パラメータは、プロセスがサポートできる暗号化の最高レベルです。これも、0、56、128のいずれかのキー長で指定します。 |
便宜上、前述の2つのパラメータを(
min,
max)の形式で表記します。たとえば、あるプロセスの値が(56, 128)の場合は、56ビットから128ビットまでの暗号化がサポートされることを示します。
|
2.
|
イニシエータ・プロセスが通信セッションを開始します。 |
|
3.
|
ターゲット・プロセスは初期接続を受け取り、通信する2つのプロセスが使用する暗号化レベルを調整します。 |
|
4.
|
2つのプロセスは、双方がサポートするキーの最大サイズについて合意します。 |
|
5.
|
構成した最大キー・サイズは、インストールされているソフトウェアの機能に合せて縮小されます。この手順はリンクの調整時に行う必要があります。構成時には、特定のマシンにインストールされている暗号化パッケージを確認できないからです。 |
|
6.
|
プロセスは、調整済の暗号化レベルでメッセージをやり取りします。 |
ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階の手順で確認されます。
|
1.
|
各プロセスで、それぞれの min-max値が確認されます。 |
|
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ドメインに対して自身を認証します。
|
•
|
なし - CORBAアプリケーションでパスワードまたはアクセスのチェックを行わないことを示します。 |
|
•
|
アプリケーション・パスワード - CORBAアプリケーションにアクセスするには、ユーザーはドメイン・パスワードを入力する必要があります。 |
|
•
|
ユーザー認証 - CORBAアプリケーションにアクセスするには、ユーザーはドメイン・パスワードだけでなくアプリケーション・パスワードも入力する必要があります。 |
|
•
|
ACL - CORBAアプリケーションで認可を使用し、インタフェース、キュー名、およびイベント名に対するアクセス制御のチェックを行います。ユーザーにACLが関連付けられていなければ、アクセス権が付与されているとみなされます。 |
|
•
|
ACL - CORBAアプリケーションで認可を使用し、インタフェース、キュー名、およびイベント名に対するアクセス制御のチェックを行います。必須のACLの値はACLと似ていますが、ユーザーにACLが関連付けられていない場合にはアクセスは拒否されます。 |
パスワードによる認証を使用する場合、クライアント・アプリケーションで
Tobj::PrincipalAuthenticator::logon()メソッドを使用する方法と、
SecurityLevel2::PrincipalAuthenticator::authenticate()メソッドを使用する方法があります。
パスワードによる認証を使用する場合、SSLプロトコルによって、アプリケーション間の通信の機密性と整合性を保護できます。詳細は、
3-9ページの「SSLプロトコル」を参照してください。
|
1.
|
開始元アプリケーションは、次のいずれかの方法でOracle Tuxedoドメインにアクセスします。 |
|
•
|
CORBA Interoperable Naming Service (INS)のブートストラップ処理メカニズムを使用します。このメカニズムを使用するのは、別のベンダーのクライアントORBを使用する場合です。CORBA INSの使い方については、Oracle Tuxedoオンライン・ドキュメントの 『CORBAプログラミング・リファレンス』を参照してください。 |
|
•
|
Oracleのブートストラップ処理メカニズムを使用します。このメカニズムを使用するのは、Oracle CORBAクライアント・アプリケーションを使用する場合です。 |
|
2.
|
開始元アプリケーションは、ユーザーの資格証明を取得します。開始元アプリケーションは、Oracle Tuxedoドメインが使用する証明資料を提示して、ユーザーを認証する必要があります。この証明資料は、ユーザー名とパスワードで構成されています。 |
|
•
|
開始元アプリケーションは、 PrincipalAuthenticatorオブジェクトを使用してセキュリティ・コンテキストを作成します。認証リクエストは、IIOPリスナー/ハンドラに送信されます。認証リクエストに含まれた証明資料は、提示された情報を検証する認証サーバーまで安全に転送されます。 |
|
•
|
検証が成功すると、Oracle Tuxedoシステムは、今後の呼出しで使用される Credentialsオブジェクトを作成します。ユーザーの Credentialsオブジェクトは、セキュリティ・コンテキストを表す Currentオブジェクトに関連付けられます。 |
|
3.
|
開始元アプリケーションは、オブジェクト・リファレンスを使用してOracle Tuxedoドメイン内のCORBAオブジェクトを呼び出します。リクエストはIIOPリクエストにパッケージ化され、すでに確立されているセキュリティ・コンテキストとの関連付けを行うIIOPリスナー/ハンドラに転送されます。 |
|
4.
|
IIOPリスナー/ハンドラは、開始元アプリケーションからリクエストを受信します。 |
|
5.
|
IIOPリスナー/ハンドラは、リクエストを開始元アプリケーションの資格証明と一緒に、適切なCORBAオブジェクトに転送します。 |
|
|
|
|
|
UBBCONFIGファイルの SECURITYパラメータを、 APP_PW、 USER_AUTH、 ACL、または MANDATORY_ACLに設定します。
|
|
|
SECURITYパラメータを USER_AUTH、ACL、または MANDATORY_ACLに構成した場合は、認証サーバー( AUTHSRV)を UBBCONFIGファイルで構成します。
|
|
|
tpusraddおよび tpgrpaddコマンドを使用して、許可されたユーザーおよびグループ(IIOPリスナー/ハンドラを含む)のリストを定義します。
|
|
|
tmloadcfコマンドを使用して、 UBBCONFIGファイルをロードします。 UBBCONFIGファイルがロードされると、システム管理者はパスワードの入力を求められます。ここで入力するパスワードがCORBAアプリケーションのパスワードになります。
|
表3-3
パスワードによる認証のプログラミング手順
|
|
|
|
|
Bootstrapオブジェクトを使用してOracle TuxedoドメインのSecurityCurrentオブジェクトへのリファレンスを取得するコード、またはCORBA INSを使用してPrincipalAuthenticatorオブジェクトへのリファレンスを取得するコードを記述します。 |
|
|
SecurityCurrentオブジェクトからPrincipalAuthenticatorオブジェクトを取得するアプリケーション・コードを記述します。 |
|
|
Tobj::PrincipalAuthenticator::logon()または SecurityLevel2::PrincipalAuthenticator::authenticate()オペレーションを使用して、Oracle Tuxedoドメインのセキュリティ・コンテキストを取得するアプリケーション・コードを記述します。
|
|
|
UBBCONFIGファイルがロードされたときに定義したパスワードの入力をユーザーに要求するアプリケーション・コードを記述します。
|
Oracle Tuxedo製品では、業界標準のSSLプロトコルを使用して、クライアント・アプリケーションとサーバー・アプリケーション間で安全な通信を確立します。SSLプロトコルを使用する場合、プリンシパルはデジタル証明書を使用して、自身のIDをピアに対して証明します。
CORBAセキュリティ環境のSSLプロトコルのデフォルト動作では、IIOPリスナー/ハンドラが自身のIDを、デジタル証明書を使用してSSL接続を開始したプリンシパルに対して証明します。デジタル証明書は、各デジタル証明書が改ざんされていないこと、また有効期限が切れていないことを確認されます。一連の処理でデジタル証明書に問題があった場合、SSL接続は終了します。また、デジタル証明書の発行者は信頼性のある認証局のリストと照合され、IIOPリスナー/ハンドラから受信したデジタル証明書がOracle Tuxedoドメインの信頼する認証局が署名したものであるかどうか確認されます。
LLEと同じく、SSLプロトコルをパスワードによる認証で使用すると、クライアント・アプリケーションとOracle Tuxedoドメイン間の通信の機密性と整合性を保護できます。SSLプロトコルをパスワードによる認証で使用する場合、
tmloadcfコマンドを入力したときに
SEC_PRINCIPAL_NAMEパラメータで定義したIIOPリスナー/ハンドラのパスワードの入力を求められます。
|
1.
|
IIOPリスナー/ハンドラは、デジタル証明書を開始元アプリケーションに提示します。 |
|
2.
|
開始元アプリケーションは、信頼性のある認証局のリストとIIOPリスナー/ハンドラのデジタル証明書を照合します。 |
|
3.
|
開始元アプリケーションがIIOPリスナー/ハンドラのデジタル証明書を検証すると、アプリケーションとIIOPリスナー/ハンドラ間でSSL接続が確立されます。 |
開始元アプリケーションは、パスワードまたは証明書による認証を使用して、自身をOracle Tuxedoドメインに対して認証します。
CORBAアプリケーションでSSLプロトコルを使用するには、SSLプロトコルおよびPKIを有効にするライセンスをインストールする必要があります。セキュリティ機能のライセンスのインストール方法については、
『Oracle Tuxedoシステムのインストール』を参照してください。
SSLプロトコルの実装は柔軟性が高いので、ほとんどの公開鍵インフラストラクチャに対応します。Oracle Tuxedo製品では、デジタル証明書をLDAP対応のディレクトリに保存する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、CORBAアプリケーションで使用するデジタル証明書および秘密鍵の取得先の認証局を選択する必要があります。LDAP対応のディレクトリ・サービスおよび認証局を準備してからでないと、SSLプロトコルをCORBAアプリケーションで使用できません。
|
注意:
|
Oracle CORBA C++ ORBをサーバー・アプリケーションとして使用している場合、ORBでもSSLプロトコルを使用するように構成できます。詳細は、 6-1ページの「SSLプロトコルの構成」を参照してください。 |
|
|
|
|
|
LDAP対応ディレクトリ・サービスを構成します。Oracle Tuxedo製品のインストール時に、LDAPサーバーの名前を入力する必要があります。 |
|
|
SSLプロトコルを使用するためのライセンスをインストールします。 |
|
|
IIOPリスナー/ハンドラのデジタル証明書および秘密鍵を認証局から取得します。 |
|
|
IIOPリスナー/ハンドラおよび認証局のデジタル証明書をLDAP対応ディレクトリ・サービスで公開します。 |
|
|
ISLサーバー・プロセスの SEC_PRINCIPAL_NAME、 SEC_PRINCIPAL_LOCATIONおよび SEC_PRINCIPAL_PASSVARパラメータを UBBCONFIGファイルで定義します。 |
|
|
UBBCONFIGファイルの SECURITYパラメータを NONEに設定します。
|
|
|
ISLコマンドの -Sオプションを使用して、IIOPリスナー/ハンドラの安全な通信用のポートを定義します。 |
|
|
IIOPリスナー/ハンドラが信頼する認証局を定義する信頼性のある認証局ファイル( trust_ca.cer)を作成します。 |
|
|
tmloadcfコマンドを使用して、 UBBCONFIGファイルをロードします。
|
|
|
オプションで、IIOPリスナー/ハンドラのピア規則ファイル( peer_val.rul)を作成します。 |
|
|
オプションで、社内のディレクトリ階層に合せてLDAP検索フィルタ・ファイルを変更します。 |
SSLプロトコルをパスワードによる認証で使用する場合、
UBBCONFIGファイルの
SECURITYパラメータを目的の認証レベルに設定し、必要であれば、認証サーバー(
AUTHSRV)を構成します。パスワード認証の管理手順については、
3-5ページの「パスワードによる認証」を参照してください。
図3-4に、SSLプロトコルを使用する場合のCORBAアプリケーションの構成を示します。
証明書による認証では、SSL接続の両端がそれぞれのIDを互いに証明する必要があります。CORBAセキュリティ環境では、IIOPリスナー/ハンドラは自身のデジタル証明書を、SSL接続を開始したプリンシパルに対して提示します。イニシエータは、IIOPリスナー/ハンドラが使用する一連のデジタル証明書を提示して、イニシエータのIDを証明します。
一連のデジタル証明書の検証に成功すると、IIOPリスナー/ハンドラはデジタル証明書のサブジェクトから識別名の値を取り出します。CORBAセキュリティ環境では、サブジェクトの識別名の電子メール・アドレス要素をプリンシパルのIDとして使用します。IIOPリスナー/ハンドラは、プリンシパルのかわりにプリンシパルのIDを使用してプリンシパルを偽装し、開始元アプリケーションとOracle Tuxedoドメイン間のセキュリティ・コンテキストを確立します。
プリンシパルが認証されたら、リクエストを開始したプリンシパルとIIOPリスナー/ハンドラは、双方がサポートしている暗号化の種類とレベルを表す暗号スイートについて合意します。また、暗号鍵についても合意し、以降のすべてのメッセージについて同時に暗号化を開始します。
一般に、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の値を設定します。強制レベルは次のとおりです。
これがデフォルトの設定です。証明書チェーンのV1またはV2証明書に対してはチェックは行われません。V3 CA証明書の基本制約がチェックされ、証明書がCA証明書であることが検証されます。
TUX_SSL_ENFORCECONSTRAINTS=1
このレベルでは、レベル1と同じチェックに加え、次の2つの条件が適用されます。
|
•
|
証明書チェーン内のすべてのCA証明書がV3証明書でなければなりません。 |
|
•
|
CA証明書の基本制約は、IETF RFC 2459に従って「クリティカル」として指定されていなければなりません。 |
現在使用できるV3 CA証明書の一部では基本制約がクリティカルとして指定されないため、これはデフォルトではありません。
TUX_SSL_ENFORCECONSTRAINTS=2
|
注意:
|
12.1.1より前のバージョンのTuxedoでは、値に0を指定して、基本制約の強制全体を無効にすることもできました。このオプションは、基本制約がX.509規格のまだ新しい機能であった頃に、古い証明書との互換性を提供するために用意されていました。もはや必要ないため、Tuxedo 12.1.1以降では TUX_SSL_ENFORCECONSTRAINTS=0は指定できません。 |
|
1.
|
開始元アプリケーションは、次のいずれかの方法でOracle Tuxedoドメインにアクセスします。 |
|
•
|
CORBA INSのブートストラップ処理メカニズムを使用します。このメカニズムを使用するのは、別のベンダーのクライアントORBを使用する場合です。CORBA INSの使い方については、Oracle Tuxedoオンライン・ドキュメントの 『CORBAプログラミング・リファレンス』を参照してください。 |
|
•
|
Oracleのブートストラップ処理メカニズムを使用します。このメカニズムを使用するのは、OracleクライアントORBを使用する場合です。 |
|
2.
|
開始元アプリケーションは、URL ( corbaloc://host:portまたは corbalocs://host:portの形式)を使用してBootstrapオブジェクトをインスタンス化し、 SecurityLevel2::PrincipalAuthenticator::authenticateオペレーションの結果として返される SecurityLevel2::Credentialsオブジェクトの属性を設定して、保護の要件を制御します。 |
|
注意:
|
SecurityLevel2::Current::authenticate()メソッドを使用しても、ブートストラップ処理のセキュリティを確保し、証明書による認証を使用するように指定できます。
|
|
3.
|
開始元アプリケーションは、プリンシパルのデジタル証明書および秘密鍵を取得します。この情報を取得するには、プリンシパルの秘密鍵および証明書にアクセスするための証明資料の提示が必要な場合があります。通常、証明資料はパスワードではなくパス・フレーズです。 |
SecurityLevel2::PrincipalAuthenticator::authenticate()メソッドの結果として、セキュリティ・コンテキストが確立されます。
IIOPリスナー/ハンドラは、認証プロセスの一部として、アプリケーションのデジタル証明書を受信して検証します。
|
4.
|
検証が成功すると、Oracle Tuxedoシステムは Credentialsオブジェクトを作成します。プリンシパルの Credentialsオブジェクトは、現在の実行スレッドのセキュリティ・コンテキストを表します。 |
|
5.
|
開始元アプリケーションは、オブジェクト・リファレンスを使用してOracle Tuxedoドメイン内のCORBAオブジェクトを呼び出します。 |
|
6.
|
リクエストはIIOPリクエストにパッケージ化され、すでに確立されているセキュリティ・コンテキストとの関連付けを行うIIOPリスナー/ハンドラに転送されます。 |
|
7.
|
リクエストはデジタル署名され、暗号化されてから、IIOPリスナー/ハンドラに送信されます。Oracle Tuxedoシステムは、リクエストの署名と暗号化を実行します。 |
|
8.
|
IIOPリスナー/ハンドラは、開始元アプリケーションからリクエストを受信します。リクエストが復号化されます。 |
|
9.
|
IIOPリスナー/ハンドラは、プリンシパルのsubjectDNの電子メール・コンポーネントを受信し、ユーザーのIDとして使用します。 |
|
10.
|
IIOPリスナー/ハンドラは、リクエストをプリンシパルの関連トークンと一緒に、適切なCORBAオブジェクトに転送します。 |
CORBAアプリケーションで証明書による認証を使用するには、SSLプロトコルおよびPKIを有効にするライセンスをインストールする必要があります。ライセンスのインストール方法については、
『Oracle Tuxedoシステムのインストール』を参照してください。
|
|
|
|
|
LDAP対応ディレクトリ・サービスを構成します。Oracle Tuxedo製品のインストール時に、LDAPサーバーの名前を入力する必要があります。 |
|
|
SSLプロトコルを使用するためのライセンスをインストールします。 |
|
|
IIOPリスナー/ハンドラのデジタル証明書および秘密鍵を認証局から取得します。 |
|
|
CORBAクライアント・アプリケーションのデジタル証明書および秘密鍵を認証局から取得します。 |
|
|
CORBAクライアント・アプリケーションおよびIIOPリスナー/ハンドラの秘密鍵ファイルをユーザーのホーム・ディレクトリまたは $TUXDIR/udataobj/security/keysに格納します。 |
|
|
IIOPリスナー/ハンドラ、CORBAアプリケーション、および認証局のデジタル証明書をLDAP対応ディレクトリ・サービスで公開します。 |
|
|
ISLサーバー・プロセスの SEC_PRINCIPAL_NAME、 SEC_PRINCIPAL_LOCATION、および SEC_PRINCIPAL_PASSVARを UBBCONFIGファイルで定義します。 |
|
|
UBBCONFIGファイルの SECURITYパラメータを USER_AUTH、 ACL、または MANDATORY_ACLに設定します。
|
|
|
認証サーバー( AUTHSRV)を UBBCONFIGファイルで構成します。 |
|
|
tpusraddおよび tpgrpaddコマンドを使用して、CORBAアプリケーションの許可されたユーザーおよびグループを定義します。
|
|
|
ISLコマンドの -Sオプションを使用して、IIOPリスナー/ハンドラのSSL通信用のポートを定義します。 |
|
|
ISLコマンドの -aオプションを使用して、IIOPリスナー/ハンドラで証明書による認証を有効にします。 |
|
|
IIOPリスナー/ハンドラが信頼する認証局を定義する信頼性のある認証局ファイル( trust_ca.cer)を作成します。 |
|
|
CORBAクライアント・アプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル( trust_ca.cer)を作成します。 |
|
|
tmloadcfコマンドを使用して、 UBBCONFIGファイルをロードします。 SEC_PRINCIPAL_NAMEパラメータで定義されているIIOPリスナー/ハンドラのパスワードの入力を求められます。
|
|
|
オプションで、CORBAクライアント・アプリケーションおよびIIOPリスナー/ハンドラのピア規則ファイル( peer_val.rul)を作成します。 |
|
|
オプションで、社内のディレクトリ階層に合せてLDAP検索フィルタ・ファイルを変更します。 |
図3-7に、証明書による認証を使用する場合のCORBAアプリケーションの構成を示します。
|
|
|
|
|
BootstrapオブジェクトのURLアドレス形式( corbalocまたは corbalocs)を使用するアプリケーション・コードを記述します。IIOPリスナー/ハンドラの証明書の識別名のCommonNameがURLアドレス形式で指定されたホスト名と正確に一致している必要があります。URLアドレス形式の詳細は、 10-1ページの「ブートストラップ処理メカニズムの使用」を参照してください。 CORBA INSブートストラップ処理メカニズムを使用しても、Oracle TuxedoドメインのPrincipalAuthenticatorオブジェクトへのリファレンスを取得できます。CORBA INSの詳細は、 『CORBAプログラミング・リファレンス』を参照してください。 |
|
|
SecurityLevel2::PrincipalAuthenticatorインタフェースの authenticate()メソッドを使用するアプリケーション・コードを記述して認証を実行します。メソッドの引数として Tobj::CertificateBasedを指定し、 Security::Opaqueの auth_data引数として秘密鍵のパス・フレーズを指定します。
|
Oracle Tuxedo製品では、認証プラグインをCORBAアプリケーションに統合することができます。Oracle Tuxedo製品は、
共有シークレット・パスワード、
ワンタイム・パスワード、
チャレンジ・レスポンス、
Kerberosなどの認証技術を使用して、様々な認証プラグインに対応できます。認証インタフェースは、必要に応じてGSSAPI (Generic Security Service Application Programming Interface)に基づいており、認証プラグインがGSSAPIに合せて記述されていることを想定しています。
認証プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
認可の機能により、管理者はCORBAアプリケーションへのアクセスを制御できます。つまり、管理者は、認可機能を使用して、CORBAアプリケーションのリソースまたはサービスに対するアクセス権をプリンシパル(認証されたユーザー)に許可するかどうかを決定します。
CORBAセキュリティ環境では、認可プラグインを統合できます。認可は、認証トークンで提示されたユーザーIDに基づいて決定されます。認証トークンは認証プロセスで生成されるので、認証プラグインと認可プラグインとの間で調整する必要があります。
認可プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
監査とは、操作リクエストとその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、CORBAのセキュリティ・ポリシーに違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。
監査機能の現在の実装では、ログオンの失敗、偽装の失敗、および許可されなかった操作を
ULOGファイルに記録できます。操作が許可されなかった場合、どの操作のパラメータの順序もデータ型もわからないので、操作のパラメータ値は提供されません。ログオンおよび偽装に関する監査のエントリには、認証を受けようとしたプリンシパルのIDが含まれます。
ULOGファイルの設定については、
『Oracle Tuxedoアプリケーションの設定』を参照してください。
監査プラグインを使用すると、CORBAアプリケーションの監査機能を拡張できます。Oracle Tuxedoシステムは、定義済の実行ポイントで監査プラグインを呼び出します。通常、実行ポイントは、操作を試行する前、セキュリティ違反につながる現象を検出した場合、または操作が成功した場合です。監査情報を収集、処理、保護、および配布するためのアクションは、監査プラグインの機能によって異なります。監査情報を収集する場合はパフォーマンスへの影響を十分に考慮する必要があります。特に、成功した操作の監査には、大きなコストが発生することがあります。
監査に関する一部の決定は、
監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
監査リクエストの目的は、イベントを記録することです。各監査プラグインは、
success(監査が成功し、イベントが記録される)または
failure(監査は失敗し、イベントは記録されない)のどちらかのレスポンスを返します。監査プラグインは、操作の実行前と実行後にそれぞれ一度呼び出されます。
|
•
|
操作前の監査では、操作を呼び出す前にも監査し、操作後のチェックのために入力データを保存することもできます。 |
|
•
|
操作後の監査では、操作の終了ステータスが報告されます。failureステータスの場合、操作後の監査が呼び出されて、セキュリティ違反につながる現象を報告します。通常、こうしたレポートは、操作前または操作後の認可のチェックが失敗した場合や、セキュリティに対する攻撃が検出された場合に発行されます。 |
CORBAアプリケーションで監査プラグインの複数の実装を使用することができます。複数の認可プラグインを使用すると、操作前および操作後の監査操作が複数実行されます。
複数の監査プラグインを使用する場合、すべてのプラグインは、1つのマスター監査プラグインの下に配置されます。それぞれの従属認証プラグインは、
SUCCESSまたは
FAILUREを返します。いずれかのプラグインが操作に失敗すると、マスター・プラグインが出力を
FAILUREと決定します。その他のエラーも
FAILUREとみなされます。それ以外の場合、
SUCCESSが出力されます。
さらに、Oracle Tuxedoシステムのプロセスは、セキュリティ違反につながる現象を検出すると、監査プラグインを呼び出す場合があります。たとえば、操作前または操作後の認可
のチェックが失敗したり、セキュリティに対する攻撃が検出された場合などです。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを示すレスポンスを返します。
Oracle Tuxedo製品に組み込まれている監査機能を使用する場合と、監査プラグインを使用する場合では、監査のプロセスが多少異なります。デフォルトの監査機能では、操作前の監査をサポートしていません。したがって、デフォルトの監査機能が、操作前の監査を行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。
デフォルトの監査プラグイン以外の監査プラグインを使用する場合、Oracle Tuxedoシステムのレジストリでその監査プラグインを構成する必要があります。レジストリの詳細は、
8-1ページの「セキュリティ・プラグインの構成」を参照してください。
監査プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
Oracle Tuxedo製品には、CORBAアプリケーションでデジタル証明書を使用するために必要なSSLプロトコルとインフラストラクチャを含むPKI環境が用意されています。ただし、PKIインタフェースを使用して、カスタム・メッセージ・ベースのデジタル署名およびメッセージ・ベースの暗号化機能をCORBAアプリケーションに提供するPKIプラグインを統合できます。
表3-7に、PKIインタフェースを示します。
|
|
|
|
|
公開鍵ソフトウェアが公開鍵および秘密鍵を開けるようにします。たとえば、ゲートウェイ・プロセスでは、メッセージを復号化してから転送するために、特定の秘密鍵へのアクセスが必要なこともあります。 |
|
|
公開鍵ソフトウェアが公開鍵および秘密鍵を管理および使用できるようにします。なお、メッセージ・ダイジェストとセッション・キーは、このインタフェースを使用して暗号化および復号化されますが、公開鍵暗号を使用するバルク・データの暗号化は行われません。バルク・データの暗号化は、対称鍵暗号を使用して行われます。 |
|
|
公開鍵ソフトウェアが、所定のプリンシパルに対するX.509v3デジタル証明書を取得できるようにします。デジタル証明書は、Lightweight Directory Access Protocol (LDAP)など、適切な証明書リポジトリを使用して格納することができます。 |
|
|
公開鍵ソフトウェアが、簡単なプリンシパル名とX.509v3デジタル証明書を関連付けることができるようにします。パーサーは、デジタル証明書を解析して、デジタル証明書に関連付けるプリンシパル名を生成します。 |
|
|
公開鍵ソフトウェアが特定のビジネス・ロジックに基づいてX.509v3デジタル証明書を検証することができます。 |
|
|
公開鍵ソフトウェアは、鍵を開くために必要な証明資料にアクセスしたり、認可トークンおよび監査トークンを提供したりすることができます。 |
PKIインタフェースは、次のアルゴリズムをサポートしています。
|
•
|
公開鍵アルゴリズム: RSA (Rivest、Shamir、Adelmanの頭文字を取ったもの)およびDigital Signature Algorithm (DSA) |
|
•
|
DES-CBC (Data Encryption Standard for Cipher Block Chaining) |
|
•
|
Secure Hash Algorithm 1 (SHA-1) |
PKIプラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
ここでは、CORBAのセキュリティ機能についてよく寄せられる質問をいくつか取り上げて回答します。
既存のCORBAアプリケーションのセキュリティ機能を変更する必要がありますか
いいえ、必要ありません。CORBAアプリケーションで以前のバージョンのWebLogic Enterpriseのセキュリティ・インタフェースを使用している場合、CORBAアプリケーションを変更する必要はありません。現在のセキュリティ・スキームをそのまま使用しても、既存のCORBAアプリケーションは8.0以降のOracle TuxedoでビルドしたCORBAアプリケーションと協調動作します。
たとえば、CORBAアプリケーションが、接続したすべてのクライアント・アプリケーションに一般的な情報を提供する一連のサーバーで構成されている場合、セキュリティ・スキームを強化する必要はまったくありません。CORBAアプリケーションが、スニッファを検出できるだけのセキュリティ機能を持つ内部ネットワークのクライアント・アプリケーションに情報を提供する一連のサーバー・アプリケーションで構成されている場合、新たなセキュリティ機能を実装する必要はありません。
既存のCORBAアプリケーションでSSLプロトコルを使用できますか
答えは「はい」です。SSLプロトコルを既存のCORBAアプリケーションで使用すると、さらにセキュリティ機能を強化することができます。たとえば、株価を特定のクライアント・アプリケーションに提供するCORBAサーバー・アプリケーションでは、SSLプロトコルを使用すると、クライアント・アプリケーションが正しいCORBAサーバー・アプリケーションに接続しており、不正なデータを持つ偽のCORBAサーバー・アプリケーションにルーティングされていないことを保証できます。クライアント・アプリケーションを認証する証明資料としては、ユーザー名とパスワードで十分です。しかし、SSLプロトコルを使用することで、メッセージのリクエスト/応答情報をさらに高いレベルのセキュリティ機能で保護できます。
SSLプロトコルを使用すると、CORBAアプリケーションに次の利点があります。
|
•
|
初期ブートストラップ処理を含む会話全体を保護できます。SSLプロトコルは、中間者攻撃、リプレイ攻撃、改ざん、およびスニッフィングを防ぐことができます。 |
|
•
|
SSLプロトコルでは、最低56ビットの暗号化がデフォルト設定されているので、デフォルト設定をそのまま使用するだけでも、署名と暗号化による保護機能が提供されます。 |
|
•
|
IIOPリスナー/ハンドラのデジタル証明書を使用して、接続されているIIOPリスナー/ハンドラをクライアント側で検証できます。クライアント・アプリケーションでは、セキュリティ規則を追加して、IIOPリスナー/ハンドラによるクライアント・アプリケーションへのアクセスを制限できます。コールバック・オブジェクトを使用すると、この保護機能はリモート・サーバー・アプリケーションに接続するIIOPリスナー/ハンドラにも適用できます。 |
CORBAアプリケーションでSSLプロトコルを使用するには、デジタル証明書を使用するインフラストラクチャを設定し、SSLプロトコルを使用するようにISLサーバー・プロセスのコマンド行オプションを変更した上で、IIOPリスナー/ハンドラの安全な通信用のポートを構成します。既存のCORBAアプリケーションがパスワードによる認証を使用する場合、SSLプロトコルでそのコードを使用できます。CORBA C++クライアント・アプリケーションが、Bootstrapオブジェクトへの初期参照を解決して認証を実行する際に、
InvalidDomain例外を捕捉しない場合は、この例外を処理するコードを記述します。詳細は、
3-22ページの「PKIプラグイン」を参照してください。
既存のCORBAアプリケーションを移行して、CORBAアプリケーションと市販のWebブラウザ間でインターネット接続を使用するときです。たとえば、CORBAアプリケーションのユーザーがインターネット上で買い物をするとします。ユーザーに対して次の点を保証する必要があります。
|
•
|
アクセス先が目的のオンライン・ストアがあるサーバーであって、クレジット・カード情報を盗むためにオンライン・ストアを装った偽のサーバーではないこと。 |
|
•
|
CORBAアプリケーションとオンライン・ストア間でやり取りするデータを、ネットワーク上の侵入者に知られないこと。 |
|
•
|
オンライン・ストアとやり取りするデータが途中で変更されないこと。$500相当の商品の注文が、悪意の有無にかかわらず、$5000の注文に変えられることがないこと。 |
こうした場合、SSLプロトコルおよび証明書による認証を使用すると、CORBAアプリケーションで最高レベルの保護機能が提供されます。SSLプロトコルによる利点以外にも、証明書による認証を使用すると、CORBAアプリケーションに次の利点があります。
|
•
|
クライアント・アプリケーションのデジタル証明書を使用して、IIOPリスナー/ハンドラ側でクライアント・アプリケーションを検証できます。また、IIOPリスナー/ハンドラでは、デジタル証明書のIDに基づいてクライアント・アプリケーションへのアクセスを制限する規則を追加できます。サーバー・アプリケーションとして機能するリモートORBを構成すると、相互認証を有効にして、デジタル証明書に基づいてクライアント・アプリケーションのIDを検証できます。 |
|
•
|
Oracle Tuxedoドメイン内では、クライアント・アプリケーションにOracle Tuxedoユーザー名およびパスワードを割り当てることができます。IIOPリスナー/ハンドラは、デジタル証明書に定義されているIDをOracle Tuxedoユーザー名およびパスワードにマップするので、既存のCORBAアプリケーションはネイティブCORBAサーバー・アプリケーション内にIDを持つことができます。 |
