bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0

Tuxedo CORBA アプリケーションのセキュリティ機能

 Previous Next Contents Index View as PDF  

CORBA セキュリティ機能の概要

ここでは、以下の内容について説明します。

注記 BEA Tuxedo のリリース 8.0 には、アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) アプリケーションおよび CORBA アプリケーションをビルドできる環境が用意されています。このマニュアルでは、CORBA アプリケーションでセキュリティをインプリメントする方法について説明します。ATMI アプリケーションでセキュリティをインプリメントする方法については、『BEA Tuxedo のセキュリティ機能』を参照してください。

 


CORBA セキュリティ機能

セキュリティとは、コンピュータ内のデータまたはコンピュータ間で送受信されるデータが損なわれないことを保証する技術のことです。ほとんどのセキュリティ機能では、証明資料およびデータの暗号化を使用してセキュリティを実現します。証明資料とは、秘密の文字列であり、ユーザはこれを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、解釈不能な形式にデータを変換することです。

電子商取引などで使用される分散アプリケーションには、悪質なユーザがデータを傍受したり、操作を中断したり、不正な情報を入力できるアクセス・ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、こうした悪質なユーザによる攻撃を受けやすくなります。したがって、このようなアプリケーションの基盤となる分散型のコンピューティング・ソフトウェア、つまりミドルウェアは、セキュリティ機能を備えている必要があります。

BEA Tuxedo 製品の CORBA セキュリティ機能を利用すると、クライアント・アプリケーションとサーバ・アプリケーションの間で安全な接続を確立できます。以下の機能があります。

CORBA 環境のすべてのセキュリティ機能を利用するには、SSL プロトコル、LLE、および PKI を有効にするライセンスをインストールする必要があります。セキュリティ機能のライセンスのインストール方法については、『BEA Tuxedo システムのインストール』を参照してください。

注記 『BEA Tuxedo CORBA アプリケーションのセキュリティ機能』では、BEA Tuxedo 製品に用意されている CORBA 環境のセキュリティ機能について説明しています。BEA Tuxedo 製品に用意されている ATMI 環境のセキュリティ機能の使用方法については、『BEA Tuxedo のセキュリティ機能』を参照してください。

表 1-1 は、BEA Tuxedo 製品の CORBA セキュリティ機能の特徴をまとめたものです。

.

表 3-1 CORBA セキュリティ機能

セキュリティ機能

説明

サービス・プロバイダ・インターフェイス (SPI)

デフォルトのインプリメンテーション

認証

ユーザまたはシステム・プロセスに対して指定されている ID を証明し、ID 情報を安全に記録および転送し、必要に応じて ID 情報を利用可能にします。

1 つのインターフェイスとして実装されます。

認証なし、アプリケーション・パスワードを使用、証明書による認証、という 3 つのセキュリティ・レベルが用意されています。

認可

ID およびその他の情報に基づいて、リソースへのアクセスを制御します。

1 つのインターフェイスとして実装されます。

N/A

監査

操作要求とその結果に関する情報を安全に収集、格納、および配布します。

1 つのインターフェイスとして実装されます。

デフォルトの監査機能は、ユーザ・ログ機能 (ULOG) によって実装されます。

リンク・レベルの暗号化

対称鍵による暗号化を使用して、CORBA アプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージのデータ機密性を保護します。

N/A

RC4 形式の対称鍵による暗号化

セキュア・ソケット・レイヤ (SSL) プロトコル

対称鍵による暗号化を使用して、BEA Tuxedo ドメイン間をつなぐネットワーク・リンク上で送受信されるメッセージのデータ機密性を保護します。

N/A

SSL バージョン 3.0 プロトコル

シングル・サイン・オン

WebLogic Server ユーザの ID を BEA Tuxedo ドメインに伝達します。

N/A

N/A

公開鍵によるセキュリティ機能

公開鍵 (または非対称鍵) 暗号化を使用して、リモート・クライアント・アプリケーションと IIOP リスナ/ハンドラ間をつなぐネットワーク・リンク上で送受信されるメッセージのデータ機密性を保護します。X.509 デジタル証明書に基づく相互認証に対応した SSL バージョン 3.0 に準拠しています。

次のインターフェイスとして実装されます。

デフォルトの公開鍵セキュリティでは、次のアルゴリズムがサポートされます。


 

 


CORBA セキュリティ環境

BEA Tuxedo CORBA 環境などの分散型のエンタープライズ・ミドルウェア環境で、エンド・ツー・エンドの相互認証を直接行う場合、特に、長時間の接続用に最適化されたセキュリティ・メカニズムでは、大幅にコストがかかります。プリンシパルから各サーバ・アプリケーションに対して直接ネットワーク接続を確立したり、サービス要求の処理時に複数の認証メッセージを交換および検証するのは、非効率的です。代わりに、BEA Tuxedo 製品の CORBA アプリケーションは、図3-1 のような、高信頼性委譲型認証モデルを実装しています。

図 3-1 高信頼性委譲型モデル


 

高信頼性委譲型モデルでは、プリンシパル (一般にはクライアント・アプリケーションのユーザ) は信頼性のあるシステム・ゲートウェイ・プロセスに対して認証を行います。CORBA アプリケーションの場合、信頼性のあるシステム・ゲートウェイ・プロセスは IIOP リスナ/ハンドラです。認証が成功すると、セキュリティ・トークンが開始元プリンシパルに割り当てられます。セキュリティ・トークンとは、プロセス間の転送に適したオペークなデータ構造体です。

IIOP リスナ/ハンドラは、認証済みのプリンシパルから要求を受信すると、認証および監査用にプリンシパルのセキュリティ・トークンをアタッチして、ターゲット・サーバ・アプリケーションに送ります。

高信頼性委譲型モデルでは、IIOP リスナ/ハンドラは BEA Tuxedo ドメインの認証ソフトウェアがプリンシパルの ID を確認することを前提にして、適切なセキュリティ・トークンを生成します。サーバ・アプリケーションは、IIOP リスナ/ハンドラが正しいセキュリティ・トークンをアタッチすることを前提にしています。また、サーバ・アプリケーションは、プリンシパルの要求に関わるほかのサーバ・アプリケーションがセキュリティ・トークンを安全に転送することを前提にしています。

開始元のクライアント・アプリケーションと IIOP リスナ/ハンドラの間のセッションは、以下のように確立されます。

  1. クライアント・アプリケーションが BEA Tuxedo ドメイン内のオブジェクトにアクセスする場合、クライアント・アプリケーションはユーザ名およびパスワードまたは X.509 デジタル証明書を使用して、IIOP リスナ/ハンドラとの接続を認証します。

  2. プリンシパルと IIOP リスナ/ハンドラの間で、セキュリティが関連付けられます (セキュリティ・コンテキスト)。このセキュリティ・コンテキストを使用して、BEA Tuxedo ドメイン内のオブジェクトへのアクセスが制御されます。

    IIOP リスナ/ハンドラは、セキュリティ・コンテキストから認証および監査トークンを取り出します。認証および監査トークンは共に、セキュリティ・コンテキストに関連付けられたプリンシパルの ID を表します。

  3. 認証が完了すると、プリンシパルは BEA Tuxedo ドメイン内のオブジェクトを呼び出せます。要求は IIOP 要求にパッケージ化され、IIOP リスナ/ハンドラに転送されます。IIOP リスナ/ハンドラは、確立済みのセキュリティ・コンテキストに要求を関連付けます。

  4. IIOP リスナ/ハンドラは、開始元プリンシパルから要求を受信します。

    クライアント・アプリケーションと IIOP リスナ/ハンドラ間のメッセージが保護されるかどうかは、CORBA アプリケーションで使用されるセキュリティ技術によって決まります。BEA Tuxedo 製品では、認証情報はデフォルトで暗号化されますが、クライアント・アプリケーションと BEA Tuxedo ドメイン間を送信されるメッセージは暗号化されません。メッセージはクリア・テキストで送信されます。SSL プロトコルを使用すると、メッセージを保護できます。SSL プロトコルをコンフィギュレーションしてメッセージの整合性と機密性を保護する場合、要求はデジタル署名を付けて封印 (暗号化) してから、IIOP リスナ/ハンドラに送信されます。

  5. IIOP リスナ/ハンドラは、要求に開始元の認証および監査トークンを付けて、適切なサーバ・アプリケーションに転送します。

  6. 要求がサーバ・アプリケーションに届くと、BEA Tuxedo システムは転送された要求元プリンシパルのトークンを調べて、要求を処理するのか拒否するのかを決定します。CORBA セキュリティ機能は、認証インプリメンテーションによる決定に基づいて、要求元プリンシパルがアクセス権限を持たないオブジェクトに対する要求の処理を拒否します。

 


CORBA セキュリティ環境のシングル・サイン・オン

WebLogic Server のセキュリティ・レルムと BEA Tuxedo のドメインは、別々のスコープを持つセキュリティ定義と見なされます。それぞれは、ユーザおよびアクセス制御に関する独自のセキュリティ・データベースを持っています。ただし、WebLogic Enterprise Connectivity (WLEC) を使用すると、信頼性のある接続プールを構成する接続を介して、WebLogic Server セキュリティ・レルムで認証されたプリンシパルの ID を提示し、BEA Tuxedo ドメインで認証されたプリンシパルの ID を作成することができます。

注記 BEA Tuxedo 製品の CORBA セキュリティ環境のシングル・サイン・オン機能は一方向です。プリンシパルの ID は、WebLogic Server セキュリティ・レルムから BEA Tuxedo ドメインへの伝達のみ可能です。

図3-2 は、CORBA セキュリティ環境におけるシングル・サイン・オンのしくみを示しています。

図 3-2 CORBA セキュリティ環境のシングル・サイン・オン


 

シングル・サイン・オンを使用する場合、WebLogic Server ユーザの ID は、信頼性のある接続プールを構成するネットワーク接続を介して、BEA Tuxedo ドメイン内の CORBA オブジェクトに送信される IIOP 要求のサービス・コンテキストの一部として伝達されます。信頼性のある接続プール内の各ネットワーク接続は、定義されているプリンシパルの ID を使用して認証されています。信頼性のある接続プールを確立するには、パスワードおよび証明書を使用して認証します。

伝達された ID は、IIOP リスナ/ハンドラによって BEA Tuxedo ドメインでプリンシパル ID の代わりとして使用されます。代わりに使用される ID は、1 組のトークン (認証用と監査用にそれぞれ 1 つ) として表されます。これらのトークンは、BEA Tuxedo ドメインにあるターゲットの CORBA オブジェクトに伝達され、認証および監査で使用されます。

プリンシパル ID のマッピングを容易にするため、IIOP リスナ/ハンドラは認証プラグインを使用します。このプラグインは、プリンシパル ID を認証および監査トークンにマップします。これらのトークンは、ターゲットの CORBA オブジェクトに転送される要求の一部として伝達されます。ターゲットの CORBA オブジェクトはこれらのトークンを使用して、プリンシパルの ID など、要求のイニシエータについての情報を調べます。

SSL プロトコルを使用すると、WebLogic Server レルムからの要求の機密性と整合性を保護できます。SSL 暗号化は、BEA Tuxedo ドメイン内の CORBA オブジェクトに対する IIOP 要求向けに用意されています。要求を保護するには、SSL プロトコルを使用するように WebLogic Connectivity および CORBA アプリケーションをコンフィギュレーションする必要があります。

シングル・サイン・オンの実装方法については、シングル・サイン・オンのコンフィギュレーションを参照してください。

 


BEA Tuxedo セキュリティ SPI

図3-3 に示したように、BEA Tuxedo 製品で利用可能な認証、認可、監査、および公開鍵によるセキュリティ機能は、プラグイン・インターフェイスを通じて実装されます。このインターフェイスを使用することで、セキュリティ・プラグインを CORBA 環境に統合できるようになります。セキュリティ・プラグインは、特定のセキュリティ機能を実装するコード・モジュールです。

図 3-3 BEA Tuxedo セキュリティ・サービス・プロバイダ・インターフェイスのアーキテクチャ


 


 

BEA Tuxedo 製品には、表 3-2 に示したセキュリティ・プラグイン用のインターフェイスが用意されています。

表 3-2 BEA Tuxedo のセキュリティ・プラグイン

プラグイン

説明

認証

通信するプロセスどうしがお互いの ID を証明し合うことです。

認可

認可の機能により、管理者は CORBA アプリケーションへのアクセスを制御できます。つまり、管理者は、認可機能を使用して、CORBA アプリケーションのリソースまたはサービスに対するアクセス権をプリンシパル (認証されたユーザ) に許可するかどうかを決定します。

監査

操作要求とその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、CORBA のセキュリティ方針に違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。

公開鍵の初期化

公開鍵ソフトウェアが公開鍵および秘密鍵を開けるようにします。たとえば、ゲートウェイ・プロセスでは、メッセージを復号化してから転送するために、特定の秘密鍵へのアクセスが必要なこともあります。

鍵管理

公開鍵ソフトウェアが公開鍵および秘密鍵を管理および使用できるようにします。なお、メッセージ・ダイジェストとセッション・キーは、このインターフェイスを使用して暗号化および復号化されますが、公開鍵暗号を使用するバルク・データの暗号化は行われません。バルク・データの暗号化は、対称鍵暗号を使用して行われます。

証明ルックアップ

公開鍵ソフトウェアが、所定のプリンシパルに対する X.509v3 デジタル証明書を取得できるようにします。デジタル証明書は、Lightweight Directory Access Protocol (LDAP) など、適切な証明書リポジトリを使用して格納することができます。

証明解析

公開鍵ソフトウェアが、簡単なプリンシパル名と X.509v3 デジタル証明書を関連付けることができるようにします。パーサは、デジタル証明書を解析して、デジタル証明書に関連付けるプリンシパル名を生成します。

証明書の検証

公開鍵ソフトウェアが特定のビジネス・ロジックに基づいて X.509v3 デジタル証明書を検証することができます。

証明資料のマッピング

公開鍵ソフトウェアは、鍵を開くために必要な証明資料にアクセスしたり、認可トークンおよび監査トークンを提供したりすることができます。


 

SPI の仕様は、BEA 社と専用契約を結んだサード・パーティのセキュリティ・ベンダだけが利用できます。セキュリティ機能をカスタマイズする場合は、これらのセキュリティ・ベンダまたは BEA プロフェッショナル・サービスにお問い合わせください。たとえば、公開鍵によるセキュリティ機能をカスタマイズする場合は、適切なセキュリティ・プラグインを提供するサード・パーティのセキュリティ・ベンダまたは BEA プロフェッショナル・サービスに問い合わせる必要があります。

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

 

Back to Top Previous Next
Contact e-docsContact BEAwebmasterprivacy