ORACLE JAPAN Server Release 6.1

 

  |  

  WebLogic Server ホーム   |     WebLogic Security   |   前へ   |   次へ   |   目次   |   索引   |   PDF 版

WebLogic Security の概要

 

以下の節では、WebLogic Security について概説します。

 


WebLogic Security の機能

セキュリティとは、コンピュータに保存されているデータまたはコンピュータ間でやりとりされるデータが危険にさらされないことを保証する技術です。ほとんどのセキュリティ対策は、証明データとデータ暗号化を利用します。一般に証明データは、ユーザに特定のアプリケーションまたはシステムへのアクセスを許可する秘密の単語または句です。データ暗号化とは、データを解釈不能な形式に変換することです。

電子商取引(e- コマース)向けアプリケーションなどの分散アプリケーションでは、悪意のある何者かがデータを横取りし、処理を混乱させ、不正な入力を行う起点となる可能性があるアクセス ポイントを多数提供します。そのため、企業の分散化が進むにつれて、セキュリティ攻撃を受ける可能性も増大します。したがって、アプリケーションの分散に伴い、その基盤となる分散コンピューティング ソフトウェアによってセキュリティを実現することがますます重要になります。

WebLogic Server のセキュリティ機能を利用すると、Web ブラウザ、Java クライアント、およびほかの WebLogic Server から WebLogic Server にセキュアな接続を確立できます。さらに、セキュアな接続を経由して、WebLogic Server を BEA Tuxedo に対するクライアントとして使用することもできます。

具体的には、WebLogic Server の持つセキュリティ機能は以下のとおりです。

WebLogic EJB のセキュリティの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。

Web アプリケーションでのセキュリティの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。

 


WebLogic のセキュリティ アーキテクチャ

WebLogic Server のセキュリティ アーキテクチャは、ユーザの認可と認証を基本にしています。 図 1-1 に、WebLogic Server のセキュリティ アーキテクチャを示します。

図1-1 WebLogic Server のセキュリティ アーキテクチャ


 

認証は、WebLogic Server 環境の最初のセキュリティ レイヤです。認証とは、接続完了前に、エンティティの ID を確認するプロセスです。認証は、WebLogic Server 環境にアクセスするユーザを保護します。

WebLogic Server のデフォルトの認証方式は、一方向認証です。一方向認証は、ユーザが個人データを提出する前にセキュアな接続の確立を希望するインターネット上では一般的な方式です。WebLogic Server がクライアントのリクエストを受け取ると、WebLogic Server は提示されたユーザ名とパスワードを、WebLogic Server セキュリティ レルムで定義されているユーザ名とパスワードに照合して認証します。ユーザ名とパスワードが正しいことが確認されると、クライアントは、WebLogic Server 環境へのアクセスを許可されます。

SSL プロトコルが使用されている場合、セキュアな接続を確立するには、WebLogic Server がデジタル証明書チェーンをクライアントに提示して、ID を証明する必要があります。クライアントは信頼された認証局のデジタル証明書一式を使用して、WebLogic Server が提示したデジタル証明書の認証されたものであることを確認します。WebLogic Server 上の SSL プロトコルが相互 SSL 用にコンフィグレーションされている場合は、クライアントも ID の正当性を確認するデジタル証明書のチェーンを渡す必要があります。

WebLogic Server 環境内では、使用可能なリソースにアクセスするユーザを認可によって制御します。認可は、ユーザおよびグループの定義と WebLogic Server 内のリソースに割り当てられたパーミッションに基づいています。リソースには、イベント、サーブレット、JDBC 接続プール、パスワード、JMS 送り先、および JNDI コンテキストがあります。WebLogic Server はセキュリティ レルムを使用して、ユーザ、グループ、ACL、およびパーミッションをリソースとして論理的に編成します。WebLogic Server のリソースは、1 つのセキュリティ レルムの ACL によって保護されます。ユーザはセキュリティ レルムで定義されていないと、そのセキュリティ レルムに属するリソースにアクセスできません。

ユーザがリソースに対してメソッドを実行しようとすると、アクセスを許可するかどうかを決めるために次の手順が取られます。

  1. リソースが保護されていて、ユーザが認証を受けていない場合、ユーザは認証を要求されます。認証に失敗した場合、リクエストは拒否されます。

  2. WebLogic Server がそのメソッドを呼び出したユーザを識別します。ユーザを識別できない場合、リクエストは拒否されます。

  3. WebLogic Server は、必要なパーミッションのセットを調べて、WebLogic Server のリソースに対してメソッドを呼び出します。

  4. 呼び出しを行ったユーザが必要なパーミッションのうちの少なくとも 1 つを持っている場合、WebLogic Server はそのメソッドの呼び出しを許可します。

次の節では、WebLogic Server が各種の接続に応じてセキュリティを提供する方法について説明します。

Web ブラウザとの接続

Web ブラウザは、次のように WebLogic Server と対話します。

  1. ユーザは、Web ブラウザでリソースの URL を入力して、WebLogic Server のリソースを呼び出します。

  2. WebLogic Server の Web サーバはリクエストを受け取ります。WebLogic Server では独自の Web サーバを用意していますが、Apache Server、Microsoft Internet Information Server、および Netscape Enterprise Server も Web サーバとして使用できます。

  3. Web サーバは、要求された WebLogic Server リソースが ACL によって保護されているかどうかチェックします。WebLogic Server リソースが保護されている場合、Web サーバは確立されている HTTP 接続を使用して、ユーザのユーザ ID とパスワードを要求します。

  4. ユーザの Web ブラウザが WebLogic Server からのリクエストを受け取ると、ユーザに対してユーザ ID とパスワードを要求します。

  5. Web ブラウザは、ユーザ ID とパスワードと一緒にリクエストを再送信します。

  6. Web サーバはリクエストを Web サーバ プラグインに転送します。WebLogic Server では、Web サーバ用に以下のプラグインを提供します。

  7. 認証に成功すると、WebLogic Server は、ユーザがそのリソースへのアクセスに必要なパーミッションを持っているかどうかを調べます。

  8. 認可が成功すると、サーブレット エンジンがリクエストを遂行します。サーブレット エンジンは、WebLogic Server に入っています。

  9. サーブレットに対してメソッドを呼び出す前に、サーブレット エンジンはセキュリティ チェックを実行します。サーブレット エンジンは、このチェックで、ユーザの資格をセキュリティ コンテキストから取り出し、ユーザがサーブレットに対してメソッドを呼び出す認可を持っていることを確認します。

図 1-2 に、Web ブラウザのセキュア ログイン プロセスを示します。

図1-2 Web ブラウザのセキュア ログイン


 

HTTPS プロトコルは、ここで説明している使い方でさらに高いレベルのセキュリティを提供します。SSL プロトコルは、Web ブラウザと WebLogic Server との間で転送されるデータを暗号化するので、ユーザ ID とパスワードはクリア テキストでは転送されません。したがって、SSL プロトコルを使ってユーザのパスワードが保護されている場合、WebLogic Server はユーザを認証できます。

詳細については、以下の節を参照してください。

サーブレット、JSP、EJB、RMI オブジェクト、および Java アプリケーションとの接続

サーブレット、JSP、EJB、RMI オブジェクト、および Java アプリケーションは、Java Authentication and Authorization Service(JAAS)を使用して、WebLogic Server を認証します。JAAS は、Java 2 Software Development Kitの標準拡張機能です。JAAS の認証コンポーネントを使用すると、コードの実行形態が Java アプリケーション、JSP、EJB、RMI オブジェクト、またはサーブレットのいずれであっても、クライアントの ID を安全かつ確実に管理できます。WebLogic Server では、JAAS は既存の Security サービス プロバイダ インタフェース(SPI)の上の層に追加され、レルムベースの認可をそのまま利用できます。これが必要となる理由は、WebLogic Server が JAAS の認可コンポーネントを提供しないからです。すべての認可チェックは、基礎となるセキュリティ レルムを通して行われます。

JAAS 認証を使用する場合、Java クライアントは、Configuration オブジェクトを参照する LoginContext オブジェクトをインスタンス化することで認証プロセスを有効にします。Configuration オブジェクトは、クライアントの認証に用いるコンフィグレーション済み LoginModule を指定します。LoginModule オブジェクトは、クライアントの資格を要求して確認します。WebLogic Server で使用する認証メカニズムのタイプごとに LoginModule オブジェクトを作成する必要があることに注意してください。たとえば相互認証を使用する場合は、資格を要求するとともに提供する LoginModule オブジェクトを作成する必要があります。WebLogic Server では、LoginModule オブジェクトを提供していません。

クライアント(サーブレット、JSP、EJB、RMI オブジェクト、および Java アプリケーション)は、次の方法で、WebLogic Server と安全に対話します。

  1. クライアントは、LoginModule オブジェクトと CallbackHandler オブジェクトをインスタンス化する LoginContext を作成します。

  2. クライアントは、LoginContext オブジェクトの login() メソッドを呼び出します。次に、login() メソッドが指定された LoginModule を呼び出します。

  3. LoginModule は、クライアントの資格を要求して確認します。

  4. 認証に成功すると、WebLogic Server は、クライアントが要求したリソースへのアクセスに必要なパーミッションを持っているかどうかを調べます。パーミッションは、WebLogic Server セキュリティ レルムで定義されたリソースの ACL で調べます。

  5. ACL の認可が成功すると、クライアントからのリクエストが WebLogic Server によって遂行されます。

パスワード認証を実装する LoginModule を使用する場合は、SSL プロトコルを利用するよう WebLogic Server をコンフィグレーションできます。SSL プロトコルは、ユーザ ID とパスワードがクリア テキストでは転送されないように、クライアントと WebLogic Server との間で転送されるデータを暗号化します。

図 1-3 に、サーブレット、JSP、EJB、RMI オブジェクト、および Java アプリケーションのセキュア ログイン プロセスを示します。

図1-3 Java クライアント用のセキュア ログイン


 

WebLogic Server は、別の WebLogic Server に対するクライアントとして機能できます。この場合、WebLogic Server はクライアントと同じ認証方法を使用します。

注意: WebLogic Server では、認証を渡す方法として JNDI メソッドもサポートしています。ただし、この機能は JAAS 認証に置き換えられます。

詳細については、以下の節を参照してください。

管理サーバとの接続

WebLogic Server では、管理サーバとは、すべてのコンフィグレーション情報の中央ソースとしての役割を持つ WebLogic Server のことです。管理サーバは、1 つの WebLogic Server または複数の WebLogic Server から構成されるクラスタのコンフィグレーション情報を格納できます。管理サーバとその他の WebLogic Server との接続は、盗聴、改ざん、反復、偽装などの攻撃から保護する必要があります。

SSL プロトコルと証明書を使用する場合、管理サーバは、管理対象の WebLogic Server が起動されるたびに自身のデジタル証明書をそのサーバ対して提示します。次に管理対象 WebLogic Server は、デジタル証明書内の情報を利用して管理サーバを認証します。

管理サーバのデジタル証明書は、BEA から提供されます。デジタル証明書は、WebLogic Server のインストール時に \wlserver6.1\config\mydomain にインストールされます。

デフォルトでは、管理サーバとその他の WebLogic Server との接続は安全ではありません。ユーザ名とパスワードが入ったファイルは暗号化されていません。ユーザ名とパスワードは接続を介してクリア テキストで送信され、コンフィグレーション情報は保護されません。このため、SSL プロトコルと証明書を使用して、管理サーバ内のコンフィグレーション情報を保護することをお勧めします。

図 1-4 に、管理サーバと管理対象 WebLogic Server との間のセキュア ログイン プロセスを示します。

図1-4 管理対象サーバと管理サーバ用のセキュア ログイン


 

詳細については、「セキュリティの管理」を参照してください。

 


BEA Tuxedo に対するクライアントとしての WebLogic Server の使い方

WebLogic Server セキュリティ レルムのセキュリティのスコープは、BEA Tuxedo ドメイン内のスコープとは異なります。それぞれがユーザの独自のセキュリティ ストアを持ち、独自にアクセスを制御します。ただし、WebLogic Enterprise Connectivity を使用することで、信頼された WLEC 接続プールの一部をなす接続を介して、WebLogic Server セキュリティ レルムで認証済みユーザの ID から BEA Tuxedo ドメイン内の認証済みプリンシパルの ID を形成できます。この機能は、セキュリティ コンテキストの伝播と呼ばれます。

注意: WebLogic Server 製品でのセキュリティ コンテキストの伝播は一方向のみです。つまり、ユーザの ID は、WebLogic Server セキュリティ レルムから BEA Tuxedo ドメインへの方向にのみ伝播できます。

図 1-5 に、WebLogic Server 環境と BEA Tuxedo 環境との間でセキュリティ コンテキストが伝播される仕組みを示します。

図1-5 WebLogic Server と BEA Tuxedo との間のセキュリティ コンテキストの伝播


 

セキュリティ コンテキストを伝播する場合、WebLogic Server ユーザのセキュリティ ID が、IIOP リクエストのサービス コンテキストの一部に含まれます。このリクエストは、WLEC 接続プールの一部をなすネットワーク接続を経由して、BEA Tuxedo ドメインに送信されます。WLEC 接続プール内の各ネットワーク接続は、定義済みのユーザ ID を使用して認証されます。WLEC 接続プールを確立するには、パスワードと証明書の両方を使用します。

伝播されたセキュリティ ID は、IIOP リスナ/ハンドラが BEA Tuxedo ドメイン内でユーザの役割を果たすために使用します。ユーザの役割を果たす ID は、認可用と監査用にそれぞれ 1 つのトークンのペアで表されます。これらのトークンは、BEA Tuxedo ドメインの対象 CORBA オブジェクトに伝播され、認可と監査が行われる際に使用されます。

ユーザ ID のマッピングを容易にするため、BEA Tuxedo 内の IIOP リスナ/ハンドラは認証プラグインを使用します。このプラグインは、ユーザ ID を認可および監査トークンにマッピングします。マッピングされたトークンは、対象となる CORBA オブジェクトに転送されるリクエストの一部として伝播されます。対象となる CORBA オブジェクトはトークンを使用して、ユーザの ID やユーザに関連付けられているロールまたはグループの名前など、リクエストの発信元についての情報を調べます。

SSL プロトコルを使用すると、WebLogic Server セキュリティ レルムから送信されるリクエストの機密性と整合性を保護できます。SSL 暗号化は、BEA Tuxedo ドメイン内の CORBA オブジェクトに送信される IIOP リクエストを対象として行われます。リクエストを保護するには、WebLogic Connectivity と BEA Tuxedo CORBA アプリケーションの両方で、SSL プロトコルを使用するようコンフィグレーションする必要があります。

詳細については、以下の節を参照してください。

 

back to top previous page next page