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