WebLogic Security の紹介
|
 |
 |
|
この章では、WebLogic Server のセキュリティに関する以下の基礎概念について説明します。
監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査はコンピュータのアクティビティの電子的な記録を提供するものです。WebLogic Server のセキュリティ アーキテクチャでは、監査プロバイダを使用して監査サービスを提供します。
監査プロバイダがコンフィグレーションされている場合、WebLogic Security フレームワークは、セキュリティ操作 (認証や認可など) が実行される前とされた後に、監査プロバイダを呼び出し、監査イベントの記録を有効にします。個々のイベントを監査するかどうかの決定は監査プロバイダによって行われ、特定の監査基準または重大度レベルあるいはその両方に基づいて決定することができます。監査情報を記載した記録は、LDAP サーバ、データベース、シンプル ファイルなどの出力リポジトリに書き出すことができます。
認証とは、呼び出し側が、特定のユーザまたはシステムの代わりに動作していることを証明する際に使用するメカニズムのことです。認証は、ユーザ名とパスワードの組み合わせなどの資格を使用して「あなたは誰」という問いに答えます。
WebLogic Server では、ユーザまたはシステム プロセスの ID を証明するために認証プロバイダを使用します。認証プロバイダでは、ID 情報を記憶したり、転送したり、その情報が必要な場合に (サブジェクトを通じて) システムのさまざまなコンポーネントで利用できるようにしたりします。認証プロセスでは、プリンシパル検証プロバイダが、サブジェクト内に格納されるプリンシパル (ユーザおよびグループ) のセキュリティを強化するため、それらのプリンシパルに署名して信頼性を検証します。
プリンシパルは、認証の結果としてユーザまたはグループに割り当てられる ID です。WebLogic Server のようなアプリケーション サーバでは、ユーザもグループもプリンシパルとして使用することができます。JAAS (Java Authentication and Authorization Service) では、プリンシパルなどの認証情報のコンテナとしてサブジェクトを使用することになっています。
図 2-1 に、ユーザ、グループ、プリンシパル、およびサブジェクト間の関係を示します。
注意 : このリリースの WebLogic Server では、WebLogic Server 6.x ユーザに代わってサブジェクトが使用されます。
図 2-1 ユーザ、グループ、プリンシパル、およびサブジェクトの間の関係
認証に成功すると、その一環として、プリンシパルは署名され、その後の使用に備えてサブジェクトに格納されます。プリンシパルに署名するのはプリンシパル検証プロバイダであり、実際にプリンシパルをサブジェクトに格納するのは LoginModule です。後で、サブジェクト内に格納されたプリンシパルに呼び出し側がアクセスしようとすると、そのプリンシパルが署名されてから変更されていないことをプリンシパル検証プロバイダが確認したうえで、そのプリンシパルが呼び出し側に返されます (それ以外のセキュリティ条件がすべて満たされている場合)。
WebLogic Server ユーザまたはグループを表すプリンシパルは、weblogic.security.spi パッケージの WLSUser インタフェースと WLSGroup インタフェースを実装する必要があります。
クライアントが認証の必要なアプリケーション、アプレット、エンタープライズ JavaBean (EJB)、あるいはサーブレットのいずれであろうと、WebLogic Server では、JAAS (Java Authentication and Authorization Service) クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。JAAS では PAM (プラグイン可能な認証モジュール) フレームワークの Java 版を実装しており、それを使用することでアプリケーションは基礎となる認証技術からの独立性を保つことができるようになります。このため、PAM フレームワークを利用することで、アプリケーションに修正を加えることなく新しいまたは更新版の認証技術を使用することができます。
WebLogic Server は、リモートのファット クライアントの認証および内部の認証で JAAS を使用します。したがって、JAAS に直に関与する必要があるのは、カスタム認証プロバイダの開発者とリモート ファット クライアント アプリケーションの開発者だけです。シン クライアントのユーザまたはコンテナ内のファット クライアント アプリケーション (サーブレットからエンタープライズ JavaBeans を呼び出すものなど) の開発者は、JAAS を直接使用したり、その知識を身につけたりする必要はありません。
LoginModule は、認証処理における「馬車馬」のような存在です。すべての LoginModule は、セキュリティ レルム内のユーザの認証と、サブジェクト内への必要なプリンシパル (ユーザ/グループ) の格納を担当します。境界認証に使用されない LoginModule も、提示された証明情報 (たとえば、ユーザのパスワード) が正しいかどうかを確認します。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、各認証プロバイダの LoginModule は同じサブジェクトにプリンシパルを格納します。したがって、ある認証プロバイダの LoginModule によって、WebLogic Server ユーザ (WLSUser インタフェースの実装) を表すプリンシパル「Joe」が追加された場合、セキュリティ レルム内の他のすべての認証プロバイダは、「Joe」に出会ったときに同じ人物を参照する必要があります。つまり、他の認証プロバイダの LoginModule は、同じ人物を参照するために、WebLogic Server ユーザを表す別のプリンシパル (「Joseph」など) をサブジェクトに追加しようとしてはなりません。ただし、別の認証プロバイダの LoginModule は、WLSUser 以外のタイプのプリンシパルを「Joseph」という名前で追加することができます。
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、認証プロバイダの制御フラグ属性で認証プロバイダの実行順序を決定します。次に、制御フラグ属性の値を示します。
CallbackHandler は、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟な JAAS 規格です。CallbackHandler のタイプは、NameCallback、PasswordCallback、および TextInputCallback の 3 つで、いずれも javax.security.auth.callback パッケージに収められています。NameCallback と PasswordCallback は、それぞれユーザ名とパスワードを返します。TextInputCallback は、ユーザがログイン フォームの追加フィールド (ユーザ名とパスワードを取得するフィールド以外のフィールド) に入力したデータにアクセスするために使用します。TextInputCallback はフォームの追加フィールドにつき 1 つ必要で、各 TextInputCallback のプロンプト文字列はフォームのフィールド名と一致する必要があります。WebLogic Server は、フォームベースの Web アプリケーション ログインに対してだけ TextInputCallback を使用します。
アプリケーションは、CallbackHandler を実装し、それを基礎となるセキュリティ サービスに渡すことで、それらのサービスがアプリケーションと対話してユーザ名やパスワードなど特定の認証データを取得したり、エラーや警告メッセージなど特定の情報を表示したりできるようにします。
CallbackHandler は、アプリケーションに依存する形で実装されます。たとえば、グラフィカル ユーザ インタフェース (GUI) を持つアプリケーションに対する実装では、ウィンドウを表示して必要な情報をプロンプトで要求したり、エラー メッセージを表示したりできます。要求された情報をユーザからではなく、代替ソースから取得するように実装することもできます。
基礎となるセキュリティ サービスは、個々の Callbacks を CallbackHandler に渡すことによってさまざまなタイプの情報に対するリクエストを行います。CallbackHandler 実装は、渡された Callbacks に応じて情報を取得したり表示したりする方法を決定します。たとえば、基礎となるサービスがユーザを認証するためにユーザ名とパスワードを必要としていれば、NameCallback および PasswordCallback を使用します。その後、CallbackHandler は逐次的にユーザ名およびパスワードの入力を求めるか、または単一のウィンドウで両方の入力を求めるかを選択できます。
相互認証を使用すると、クライアントとサーバの両方で相互に認証が必要になります。この認証は、証明書などの形態の証明データを使用して行うことができます。WebLogic Server では、相互認証の一形態である、双方向の SSL 認証がサポートされています。ただし厳密には、相互認証は SSL 認証よりも上位のプロトコル スタックで行われます。詳細については、「一方向および双方向 SSL 認証」を参照してください。
LoginModule と一緒に用いると、ID アサーション プロバイダはシングル サインオンをサポートします。たとえば、ID アサーション プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザは何度もサインオンを求められることはありません。
ID アサーション プロバイダが使用する LoginModule では、以下のことが可能です。
単純認証の場合と違って、ID アサーション プロバイダが使用する LoginModule は証明データ (ユーザ名とパスワードなど) を検証しません。単にユーザが存在することを検証するだけです。
ID アサーション プロバイダでは、有効なトークンを WebLogic Server ユーザにマップする、ユーザ名マッパーがサポートされています。ID アサーション プロバイダは、ユーザまたはシステム プロセスの ID を断定するために使用する特定のトークン タイプをサポートするために開発します。ID アサーション プロバイダは複数のトークン タイプをサポートするように開発できますが、WebLogic Server 管理者はただ 1 つの「アクティブ」なトークン タイプを検証するように ID アサーション プロバイダをコンフィグレーションする必要があります。同じトークン タイプを検証する複数の ID アサーション プロバイダを 1 つのセキュリティ レルムに組み込むことも可能ですが、実際に検証を行うのは 1 つの ID アサーション プロバイダだけです。
注意 : X.501 および X.509 証明書に対して WebLogic ID アサーション プロバイダを使用するには、WebLogic Server 製品に付属しているデフォルトのユーザ名マッパー (weblogic.security.providers.authentication.DefaultUserNameMapperImpl) を使用するか、または独自の weblogic.security.providers.authentication.UserNameMapper インタフェースの実装を用意するかのいずれかの方法があります。詳細については、『WebLogic Security サービスの開発』の「カスタム ID アサーション プロバイダを開発する必要があるか」を参照してください。
WebLogic Server ユーザが、保護されている WebLogic リソースへのアクセスを要求する場合、必ず認証を受けなければなりません。このため、各ユーザは資格 (パスワードなど) を WebLogic Server に提示する必要があります。WebLogic Server 配布キットに含まれている WebLogic 認証プロバイダでは、以下のタイプの認証がサポートされています。
WebLogic Server では、WebLogic Server 製品の一部として提供される WebLogic 認証プロバイダ、またはさまざまなタイプの認証を実行するカスタム セキュリティ プロバイダを使用できます。WebLogic 認証プロバイダと認証のコンフィグレーション方法については、「資格マッピング プロセス」 および 『WebLogic の管理』の以下の節を参照してください。
ユーザ名/パスワード認証では、ユーザ ID とパスワードをユーザに要求し、WebLogic Server に送ります。WebLogic Server は受け取った情報をチェックして、信頼性を確認できれば、保護されている WebLogic リソースへのアクセスを許可します。
セキュア ソケット レイヤ (SSL)、または Hyper-Text Transfer Protocol with SSL (HTTPS) を使用すると、ユーザ名/パスワード認証にさらに高度なレベルのセキュリティを提供できます。SSL は、クライアントと WebLogic Server との間で転送されるデータを暗号化するので、ユーザ ID とパスワードはクリア テキストでは転送されません。したがって、WebLogic Server は、ユーザの ID およびパスワードの機密性を保持したままユーザを認証できます。
SSL または HTTPS クライアントのリクエストが送信されると、WebLogic Server は、クライアントに対してデジタル証明書を提示して応答します。クライアントによってそのデジタル証明書が確認されると、SSL 接続が確立されます。デジタル証明書は、WebLogic Server の身元を検証するエンティティ (信頼性のある認証局) によって発行されます。
相互認証の一形態である、双方向の SSL 認証を使用することもできます。双方向の SSL 認証では、クライアントとサーバの両方が証明書を提示しないと、両者の間で接続スレッドが有効になりません。 「一方向および双方向 SSL 認証」を参照してください。
注意 : 双方向の SSL 認証は、WebLogic Server 製品の一部として提供される WebLogic 認証プロバイダでサポートされています。
境界認証は、アプリケーション サーバ ドメインの外側にいるリモート ユーザの ID を認証するプロセスです。
境界認証は通常、リモート ユーザが断定された ID と、検証の実行に使用される特定の形態の対応する証明データ (一般的にはパスフレーズの形態、具体的にはパスワード、クレジット カード番号、暗証番号などの個人を識別する情報) を指定することによって行われます。
実際に ID を保証するエンティティである、認証エージェントは、さまざまな形態を取ることができます。たとえば、仮想プライベート ネットワーク (VPN)、ファイアウォール、企業認証サービスといったグローバルな ID サービスの形態を取ることができます。認証エージェントのこれらの形態には共通の特徴があります。これらはすべて、認証を受けたユーザに関する情報を調べるために後で提示する必要があるアーティファクトつまりトークンを生成するという認証プロセスを実行します。現時点では、トークンの形式はベンダごとに異なりますが、XML を使用した標準のトークン形式の定義が進められています。さらに、属性証明書に対しては、デジタル証明書用の X.509 標準に基づいた標準があります。しかし、結局のところ、アプリケーションやそれが構築されているインフラストラクチャがこの概念をサポートするよう設計されていない場合は、企業のネットワーク内のアプリケーションに対してリモート ユーザは再認証を行う必要があります。
WebLogic Server は、ID アサーションのサポートを介して境界までシングル サインオン概念を拡張できるよう設計されています (図 2-2 を参照)。WebLogic Security フレームワークの重要な一部分として提供されている ID アサーションの概念に基づくことで、WebLogic Server では Checkpoint の OPSEC、新しく登場した SAML (Security Assertion Markup Language)、または Common Secure Interoperability (CSI) v2 などのプロトコルに対する拡張、といった境界認証方式によって提供される認証メカニズムを使用して、この機能を実現できます。
境界認証をサポートするには、1 つまたは複数のトークン フォーマットをサポートするように設計された ID アサーション プロバイダを使用する必要があります。複数の異なる ID アサーション プロバイダを登録して使用できます。トークンは、WebLogic Server がサポートするさまざまなプロトコルによって提供されるメカニズムを使用して、通常のビジネス リクエストの一部として転送されます。WebLogic Server でリクエストが受け取られると、プロトコル メッセージを処理するエンティティによってメッセージ内のトークンが認識されます。この情報は、WebLogic Security フレームワークの呼び出しに使用されます。WebLogic Security フレームワークは、トークンの検証を処理する適切な ID アサーション プロバイダを呼び出します。トークンを検証し、そのトークンの信頼性を確立するために必要なすべてのアクションの実行と、保証されたユーザ ID の提供は、ID アサーション プロバイダ実装によって行われます。ユーザはアプリケーションに対して再認証を行う必要がありません。
シングル サインオン (SSO) は、ユーザが一度アプリケーション コンポーネントにサインオンすれば、他のさまざまなアプリケーション コンポーネントに (それらが独自の認証方式を使用している場合でも) アクセスできる機能です。SSO を使用すると、ユーザはすべてのアプリケーション、Web サイト、メインフレーム セッションに、1 つの ID でセキュアにログインできます。WebLogic Server では、Microsoft クライアントを使用したシングル サインオン (SSO) がサポートされています。このタイプの SSO では、Windows Active Directory 環境で認証済みの Microsoft クライアントと、HTTP ベースの認証を使用します。Windows Active Directory 環境では、セキュリティ プロトコルとして Kerberos を使用します。Kerberos は、異種のレルムのネットワーク認証を提供します。つまり、Windows ドメインにログインしたユーザは、アプリケーション サーバで実行されている Web アプリケーションにアクセスでき、Windows Active Directory の資格を使用してサーバに認証されます。アプリケーション サーバは、Kerberos をサポートするすべてのプラットフォームで実行できます。
Web サーバは、ブラウザからのリクエストを受信すると、Kerberos プロトコルを使用して認証するようブラウザにリクエストできます。このプロトコルでは、HTTP で認証が実行され、ブラウザ (ほとんどの場合 Internet Explorer) から委託資格を渡された Web アプリケーションが、ユーザに代わってそれ以降の Kerberos ベースのサービスにログインします。
HTTP サーバが Microsoft クライアントをログインさせるときには、WWW-Authorization:Negotiate ヘッダを含む 401 Unauthorized 応答が HTTP リクエストに返されます。次に、ブラウザがキー配布センター (KDC)/チケット認可サービス (TGS) にコンタクトしてサービス チケットを入手します。その際には、チケット リクエスト用の特別なサービス プリンシパル名が選択されます。返されたチケットは SPNEGO トークンにラップされており、これをエンコードしたものが HTTP リクエストによってサーバに返信されます。このトークンのラップを解き、チケットを認証します。認証が完了すると、要求された URL に対応するページが返されます。
Microsoft クライアントによる SSO が WebLogic Server でどのように実装されているかの詳細については、「Microsoft クライアント プロセスによる SSO」を参照してください。
認可とは、ユーザの ID などの情報に基づいて、ユーザと WebLogic リソースとのやり取りを管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Server では、認可プロバイダはユーザと WebLogic リソースとの対話を制限して、整合性、機密性、および可用性を確保します。
WebLogic リソースは、基底の WebLogic Server エンティティを表す構造化オブジェクトです。セキュリティ ロールとセキュリティ ポリシーを使用すると、これらのオブジェクトを権限のないアクセスから保護できます。
WebLogic リソースは階層化されています。このため、セキュリティ ロールとセキュリティ ポリシーは自由なレベルで定義できます。たとえば、エンタープライズ アプリケーション (EAR) 全体、複数の EJB を含むエンタープライズ JavaBean (EJB) JAR、その JAR 内の特定のエンタープライズ JavaBean (EJB)、その EJB 内の単一のメソッドなどに対してセキュリティ ロールとセキュリティ ポリシーを定義できます。
注意 : これらの WebLogic リソースの各実装の詳細については、WebLogic クラスの Javadoc を参照してください。詳細については、『WebLogic リソースのセキュリティ』の「WebLogic リソースのタイプ」を参照してください。
WebLogic Server 7.0 より前のバージョンでは、アクセス制御リスト (ACL) を使って WebLogic リソースを保護していました。このリリースの WebLogic Server では、WebLogic リソースに「誰がアクセスできるか」という問いに対し、ACL ではなくセキュリティ ポリシーが答えます。セキュリティ ポリシーは、WebLogic リソースと、1 つまたは複数のユーザ、グループ、またはセキュリティ ロールとの間に関連付けを定義するときに作成されます。また、セキュリティ ポリシーに時間制約を定義することもできます。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。
セキュリティ ポリシーは、定義済みの任意の WebLogic リソース (EJB リソースや JNDI リソースなど)、または WebLogic リソースの特定のインスタンス (Web アプリケーション内の EJB メソッドやサーブレット) の属性または操作に割り当てることができます。セキュリティ ポリシーを WebLogic リソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ ポリシーは、WebLogic リソースのタイプに割り当てられたセキュリティ ポリシーをオーバーライドします。定義済みの WebLogic リソースのリストについては、「WebLogic リソース」を参照してください。
セキュリティ ポリシーは、認可プロバイダのデータベースに格納されます。デフォルトでは、WebLogic 認可プロバイダがコンフィグレーションされ、セキュリティ ポリシーは組み込み LDAP サーバに格納されます。
ユーザまたはグループを使用してセキュリティ ポリシーを作成する場合は、そのユーザまたはグループがデフォルト セキュリティ レルムでコンフィグレーションされた認証プロバイダのセキュリティ プロバイダ データベースで定義されていなければなりません。セキュリティ ロールを使用してセキュリティ ポリシーを作成する場合は、そのセキュリティ ロールがデフォルト セキュリティ レルムでコンフィグレーションされたロール マッピング プロバイダのセキュリティ プロバイダ データベースで定義されていなければなりません。WebLogic 認証プロバイダおよびロール マッピング プロバイダは、デフォルトでは組み込み LDAP サーバ内のデータベースにコンフィグレーションされています。
デフォルトで、WebLogic Server には WebLogic リソース用のセキュリティ ポリシーが定義されています。これらのセキュリティ ポリシーは、セキュリティ ロールとデフォルト グローバル グループに基づいています。また、必要に応じてセキュリティ ポリシーはユーザに基づくこともできます。ただし、セキュリティ ポリシーは、ユーザまたはグループではなく、セキュリティ ロールに基づいて作成することをお勧めします。セキュリティ ロールに基づいてセキュリティ ポリシーを作成すると、ユーザまたはグループに付与されるセキュリティ ロールに基づいてアクセスを管理できます。管理の方法としてはこちらの方が効率的です。WebLogic リソースのデフォルト セキュリティ ポリシーのリストについては、『WebLogic リソースのセキュリティ』の「デフォルト セキュリティ ポリシー」を参照してください。
ContextHandler は、リソース コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール マッピング決定を行うセキュリティ プロバイダに渡す高性能な WebLogic クラスです。ContextHandler インタフェースを使用すると、内部 WebLogic リソース コンテナで WebLogic Security フレームワーク呼び出しに追加情報を渡すことができます。その結果、セキュリティ プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandler は本質的には名前と値のリストなので、セキュリティ プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandler の使用には、WebLogic リソース コンテナとセキュリティ プロバイダの間の緊密な連携が不可欠です。 ContextHandler の名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElement オブジェクトによって表されます。
現在、3 種類の WebLogic リソース コンテナ (サーブレット コンテナ、EJB コンテナ、Web サービス コンテナ) が ContextHandler を WebLogic Security フレームワークに渡します。そのため、URL (Web)、EJB、および Web サービスの各リソース タイプには、異なるコンテキスト要素が含まれます。これらのコンテキスト要素の値は、認可プロバイダまたはロール マッピング プロバイダで調べることができます。監査イベントをポストするためにセキュリティ プロバイダが実装される場合に使用する AuditContext インタフェースの実装によっても、コンテキスト要素の値を調べることができます。
特定のコンテキスト要素の値に関する詳細については、『WebLogic Security サービスの開発』の「ContextHandler と WebLogic リソース」を参照してください。
認証プロバイダの LoginModule と同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作を WebLogic リソースに対して実行するパーミッションをサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答を PERMIT、DENY、または ABSTAIN のいずれかで返します。
裁決では、セキュリティ レルムで複数の認可プロバイダがコンフィグレーションされている場合に発生するおそれのある認可上の衝突を、それぞれの認可プロバイダのアクセス決定の結果を比較検討することによって解消します。WebLogic Server では、裁決プロバイダを使用して、複数のアクセス決定から返される結果を調停し、PERMIT か DENY の最終判定を下します。また、裁決プロバイダでは、単一の認可プロバイダのアクセス決定から ABSTAIN の回答が返されたときにどうすべきかを指定することもできます。
SSL を使用することで、Web を介して接続されるアプリケーション間のセキュアな通信が可能になります。SSL 通信のコンポーネントおよび各コンポーネントの必要性については、Netscape Communications Corporation が公開している「How SSL Works」を参照してください。
WebLogic Server では、SSL 通信が完全にサポートされています。デフォルトでは、WebLogic Server では一方向 SSL 認証がコンフィグレーションされています。Administration Console を使用して、WebLogic Server に対して双方向 SSL 認証をコンフィグレーションできます。
WebLogic Server で SSL を使用するには、プライベート キー、対となる公開鍵が組み込まれたデジタル証明書、およびデジタル証明書に組み込まれたデータを検証できる信頼性のある認証局 (CA) によって署名された証明書が必要となります。デジタル証明書に署名した認証局が不明な場合は、WebLogic Server に信頼性のあるルート CA 証明書をインストールしなければならないこともあります。信頼性のある CA 証明書は、周知の認証局によって署名されます。
サーバのデジタル証明書を取得するには、公開鍵、プライベート キー、および公開鍵を含む証明書署名リクエスト (CSR) を生成します。認証局に CSR リクエストを提出し、署名されたデジタル証明書を取得する手順に従います。
プライベート キー、デジタル証明書、および必要に応じて信頼性のある CA 証明書を取得したら、WebLogic Server が ID 検証にそれらを使用できるよう、それらを格納する必要があります。WebLogic Server のこのリリースでは、プライベート キーと証明書をキーストアに格納する必要があります。下位互換性を保持するために、プライベート キーと証明書をファイルに格納することもできます。プライベート キー、公開鍵、および証明書の要件と手順の詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
ブラウザを使用して WebLogic Server アプリケーションと接続する場合に SSL を使用するには、単純に HTTPS とセキュア ポート (ポート番号 7002) を URL で指定します。次に例を示します。
https://localhost:7002/examplesWebApp/SnoopServlet.jsp
WebLogic Server では、SSL の pure-Java 実装が提供されます。一般的に、SSL は以下の機能を提供します。
SSL を使用する場合、対象 (サーバ) は常に発信元 (クライアント) に対して自身を認証します。対象が要求した場合は、発信元が対象に対して自身を認証することもあります。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。SSL 接続はデジタル証明書をやり取りするアプリケーション間のハンドシェークで始まり、使用する暗号化アルゴリズムの取り決め、そのセッションの残りで使用する暗号鍵の生成と続きます。
具体的には、SSL が提供するセキュリティ機能は以下のとおりです。
Web ブラウザを使って WebLogic Server と通信する場合は、Hypertext Transfer Protocol with SSL (HTTPS) を利用して、ネットワーク通信の安全性を確保できます。
SSL は、IP ベースのプロトコル上をトンネリングされます。トンネリングとは、各 SSL レコードをカプセル化し、別のプロトコル上でレコードを送信するために必要なヘッダと一緒にパッケージ化することです。SSL は、以下のように Web ブラウザおよび Java クライアントで使用できます。
https://myserver.com/mypage.html
WebLogic Server では、SSL バージョン 3 をサポートする Web ブラウザで HTTPS を使用できます。WebLogic Server の Java 仮想マシン (JVM) では、現在、HTTPS アダプタがサポートされていません。したがって、WebLogic Server は、Web ブラウザでの SSL 実装に依存します。
WebLogic Server では、一方向と双方向の SSL 認証がサポートされています。一方向 SSL 認証では、対象 (サーバ) が発信元 (クライアント) に対してデジタル証明書を提示して身元を証明する必要があります。クライアントは、2 つのチェックを行って、デジタル証明書を検証します。
上記のチェックの両方で true が返されると、SSL 接続が確立します。
双方向の SSL 認証では、クライアントとサーバの両方がデジタル証明書を提示しないと、両者の間で SSL 接続が有効になりません。そのため、この場合、WebLogic Server はクライアントに対して自身を認証するだけでなく (証明書認証の最低限の要件)、要求側のクライアントにも認証を要求します。双方向 SSL 認証は、アクセスを許可する対象を信頼性のあるクライアントに制限する場合に便利です。
図 2-3 に、WebLogic Server の SSL 接続と、一方向 SSL、双方向 SSL、またはその両方をサポートする接続を示します。Web ブラウザ クライアント、Web サーバ、ファット クライアント、Web サービス クライアント、および SSL サーバの接続に対して一方向 SSL または双方向 SSL のいずれかをコンフィグレーションできます。WebLogic Server は、SSL 接続が一方向または双方向のどちらにコンフィグレーションされているかを判別します。SSL は、Administration Console を使用してコンフィグレーションします。
図 2-3 WebLogic Server が SSL 接続をサポートする仕組み
WebLogic Server は、輸出向けと国内向けのどちらの強度の SSL でも使用できます。
標準の WebLogic Server 配布キットは、輸出向けの強度の SSL だけをサポートします。国内向けバージョンについては、BEA の販売代理店を通じてお求めください。
注意 : 国内向け強度の WebLogic Server が必要であり、その資格を満たしている場合には、国内向けの WebLogic Server ソフトウェア ライセンスを受け取ることになります。そのライセンスは WebLogic Server 配布キットのインストール時に使用します。
米国政府は、2000 年初めに暗号化ソフトウェアの輸出に関する規制を緩和したので、国内向けバージョンの WebLogic Server はほとんどの国でご使用いただけます。
暗号の強度が高いので、国内向け WebLogic Server 配布キットをお勧めします。
注意 : 輸出向け強度の WebLogic Server 配布キットを使って証明書署名リクエスト (CSR) (証明書に対して電子的に生成されるリクエスト) を生成する場合は、国内向け強度の SSL 接続に対応できないので、国内向けの証明書を提示するクライアントを認証できません。
詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
デジタル証明書とは、インターネットなどのネットワークを経由して、プリンシパルおよびエンティティのユニークな ID を確認するための電子的なドキュメントのことです。デジタル証明書は、認証局として知られる信頼性のある第三者によって確認されたユーザまたはエンティティの ID を、特定の公開鍵に安全にバインドします。公開鍵とプライベート キー (秘密鍵) を組み合わせることで、デジタル証明書のオーナーにユニークな ID が提供されます。
デジタル証明書を使用すると、特定の公開鍵が実際に特定のユーザまたはエンティティに属しているかどうかを確認できます。デジタル証明書の受信側は、証明書内の公開鍵を使用して、デジタル署名が対応するプライベート キーで作成されたものかどうかを確認します。こうした確認が終わると、この推論のチェーンによって、対応するプライベート キーのオーナーがデジタル証明書に名前のあるサブジェクトであること、そしてそのデジタル署名を作成したのがそのサブジェクトであることを確認できます。
一般に、デジタル証明書には以下のようにさまざまな情報が入っています。
最も広く使われているデジタル証明書のフォーマットは、ITU-T X.509 国際標準で定義されているものです。X.509 標準に準拠していればどのアプリケーションを使っても、デジタル証明書を読み書きできます。WebLogic Server の公開鍵インフラストラクチャ (PKI) では、X.509 バージョン 3 (X.509v3) に準拠したデジタル証明書が認識されます。Verisign や Entrust などの認証局から証明書を取得することをお勧めします。
詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
デジタル証明書は、認証局によって発行されます。デジタル証明書および公開鍵の発行先の ID を保証する信頼性のある第三者組織または企業はすべて、認証局になることができます。認証局は、デジタル証明書を作成する際に、証明書が改ざんされればわかるようにプライベート キーを使って署名します。認証局は、署名したデジタル証明書を要求側に返します。
要求側は、認証局の公開鍵を使って発行認証局の署名を確認します。認証局の公開鍵は、低レベル認証局の公開鍵の妥当性を保証する高レベル認証局から発行された証明書を提供することで利用できるようになります。この方式によって、認証局の階層が構築されます。この階層は、最終的に、ルート証明書と呼ばれる、最上位の自己署名証明書にたどり着きます。この証明書では、証明にそれ以外の一切の公開鍵が不要です。ルート証明書は、信頼性のある (ルート) 認証局によって発行されます。
受信側がすでに信頼性を確認済みの、該当認証局よりも高レベルの認証局が署名した該当認証局の公開鍵が入ったデジタル証明書を持っている場合、暗号化されたメッセージの受信側は、認証局の公開鍵を再帰的に信頼します。この点では、デジタル証明書はデジタルの信頼関係の踏み台です。結局、信頼する必要があるのは、ごく少数の最上位認証局の公開鍵だけです。証明書のチェーンを通じて、多数のユーザのデジタル署名の信頼を確立できます。
通信中のエンティティの ID は、このようにしてデジタル署名によって確立できますが、デジタル署名による信頼は、信頼性を確認するための公開鍵の範囲にとどまります。
詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
ホスト名検証は、SSL 接続先のホスト名が予定していた通信先、または許可された通信先であることを確認するプロセスです。Web クライアント (Web ブラウザ、WebLogic クライアント、またはクライアントとして機能している WebLogic Server) が別のアプリケーション サーバとの SSL 接続を要求する場合に、介在者の攻撃を防ぎます。
WebLogic Server の SSL ハンドシェーク機能としてのデフォルトの動作は、SSL サーバのデジタル証明書の SubjectDN にある共通名と、SSL 接続の開始に使用する SSL サーバのホスト名を比較することです。これらの名前が一致しない場合は SSL 接続が中断されます。
SSL クライアントが SSL サーバに接続すると、SSL サーバは認証のためにデジタル証明書チェーンをクライアントに提示します。提示されたチェーンに無効なデジタル証明書が含まれている場合もあります。SSL 仕様では、クライアントが無効な証明書を検出した場合、SSL 接続が中断されることになっています。しかし、Web ブラウザは、無効な証明書を無視するかどうかをユーザに確認し、証明書チェーン内の残りの証明書を使用して SSL サーバを認証できるかどうかを判別するため、チェーンの検証を継続します。トラスト マネージャを使用すると、どのような場合に SSL 接続を継続するか (または中止するか) を制御でき、上記のような矛盾した動作をなくすことができます。トラスト マネージャを使用すると、SSL 接続を続行する前にカスタム検証を実行できます。たとえば、トラスト マネージャを使用して、特定の地域 (町、州、国など) のユーザやその他の特殊な属性を持つユーザだけが SSL 接続を介してアクセスを取得できるように指定することができます。
WebLogic Server は weblogic.security.SSL.TrustManagerJSSE インタフェースを提供します。このインタフェースを使用すると、ピアのデジタル証明書内での検証エラーをオーバーライドし、SSL ハンドシェークを継続できます。また、サーバのデジタル証明書チェーンで付加的な検証を実行することで、SSL ハンドシェークを中止することもできます。
注意 : このインタフェースは新しいスタイルの証明書を受け取り、このリリースの WebLogic Server では非推奨の weblogic.security.SSL.TrustManager インタフェースの代わりに使用されます。
非対称鍵 (公開鍵ともいう) アルゴリズムは、公開鍵、プライベート キーという数学的には互いに関連性を持ちながらも異なる 2 つの鍵を利用します。
WebLogic Server の公開鍵インフラストラクチャ (PKI) でもデジタル署名のアルゴリズムがサポートされています。デジタル署名アルゴリズムは、デジタル署名を生成するためだけの公開鍵アルゴリズムのことです。
WebLogic Server では、Rivest、Shamir、Adelman (RSA) アルゴリズムがサポートされています。
公開鍵とプライベート キーの保存については、「キーストア プロバイダ」を参照してください。
対称鍵アルゴリズムでは、メッセージの暗号化と解読に同じ鍵を使用します。共通鍵暗号化システムは対称鍵アルゴリズムを使用して、通信中の 2 つのエンティティ間でやり取りされるメッセージを暗号化します。対称暗号化は、公開鍵暗号作成法よりも少なくとも 1000 倍の早さで処理を実行できます。
ブロック暗号は、プレーン テキスト (暗号化されていないテキスト) の固定長ブロックを同じ長さの暗号テキスト (暗号化済みテキスト) データ ブロックに変換する対称鍵アルゴリズムの一種です。この変換は、ランダムに生成したセッション キーの値に従って発生します。固定長はブロック サイズと呼ばれます。
WebLogic Server の PKI は以下の対称鍵アルゴリズムをサポートしています。
DES-CBC は、Cipher Block Chaining (CBC) モードの 64 ビット ブロックの暗号文です。56 ビットの鍵 (8 パリティ ビットをフル 64 ビット鍵から除去します) を使用します。
2 キー形式トリプル DES は、Encrypt-Decrypt-Encrypt (EDE) モードの 128 ビット ブロックの暗号です。2 キー形式トリプル DES では、2 つの 56 ビット鍵 (実効では 112 ビットの鍵 1 つ) を利用します。
現在では、トリプル DES による DES 暗号鍵を保護および転送する方式が一般的となっています。つまり、入力データ (この場合にはシングル DES 鍵) を暗号化し、解読してから、もう一度暗号化します (暗号化 - 解読 - 暗号化処理)。同じ鍵を 2 回の暗号化処理に使います。
注意 : WebLogic Server ユーザは、このアルゴリズムのリストを拡張したり変更したりすることができません。
WebLogic Server は、MD5 および SHA (Secure Hash Algorithm) メッセージ ダイジェスト アルゴリズムをサポートしています。MD5 も SHA も、広く知られた一方向のハッシュ アルゴリズムです。一方向のハッシュ アルゴリズムは、メッセージを、メッセージ ダイジェストまたはハッシュ値と呼ばれる数字の固定文字列に変換します。
MD5 は高速処理可能な 128 ビット ハッシュで、32 ビット マシンで使用することを想定しています。MD5 と比べて、SHA は 160 ビット ハッシュを用いてより高度なセキュリティを提供しますが、処理速度は低下します。
暗号スイートとは、鍵交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア ハッシュ アルゴリズムを含む SSL 暗号方式の一種です。通信の整合性を保護するために使用します。たとえば、RSA_WITH_RC4_128_MD5 という暗号スイートは、鍵交換用に RSA、バルク暗号化用に 128 ビット鍵を使う RC4、およびメッセージ ダイジェスト用に MD5 を使用します。
WebLogic Server には、RSA Crypto-J 3.5 ライブラリが同梱されています。FIPS140 の検証ステータスについては、http://csrc.nist.gov/cryptval/ の検証リストで確認してください。
WebLogic Server でサポートされている RSA 暗号スイートは、表 2-1 のとおりです。
WebLogic Server のライセンスによって、通信を保護するために使用する暗号スイートの強度 (国内向けまたは輸出向け) が決まります。WebLogic Server config.xml ファイルで定義されている暗号スイートの強度がライセンスに指定されている強度を超える場合、サーバはライセンスに指定されている強度を使用します。たとえば、持っているライセンスが輸出向けで、国内向け暗号スイートを使用するよう config.xml ファイルで定義した場合は、サーバは国内向け暗号スイートを拒否し、輸出向け暗号スイートを使用します。
ファイアウォールとは、2 つのネットワーク間のトラフィックを制限する機能のことです。ファイアウォールは、ソフトウェアとハードウェア (ルータや専用のゲートウェイ マシンなど) を組み合わせて作成できます。ファイアウォールは、プロトコル、要求されたサービス、ルーティング情報、および送信元と送信先のホストまたはネットワークに基づいてトラフィックの通過を許可または拒否するフィルタを利用します。また、認証されたユーザについてもアクセスを許可する場合があります。
図 2-4 に、WebLogic Server クラスタ宛てのトラフィックをフィルタ処理するファイアウォールを使った代表的な設定を示します。
WebLogic Server では、ファイアウォールと組み合わせて、以下の機能を使用できます。
WebLogic Server 接続フィルタを使用して、プロトコル、IP アドレス、および DNS ノード名に基づいてネットワーク トラフィックをフィルタ処理するファイアウォールを設定できます。詳細については、『WebLogic Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照してください。
ID アサーション プロバイダを使用して、境界認証 (トークンを使用する特別なタイプの認証) を設定できます。WebLogic Server のセキュリティ アーキテクチャは、境界に基づく認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティ トークン タイプ/プロトコル (SOAP、IIOP-CSIv2) を処理する ID アサーション プロバイダをサポートします。
ユーザ認証とユーザ認可を実装および使用するために、BEA WebLogic Server では、Java 2 Platform、Enterprise Edition (J2EE) の SDK バージョン 1.4.1 のセキュリティ サービスが利用されます。他の J2EE コンポーネントと同様、セキュリティ サービスも標準化されたモジュール コンポーネントに基づいています。BEA WebLogic Server は、標準に従ってこれらの Java セキュリティ サービス メソッドを実装し、細かなアプリケーションの動作をプログラミングを必要とせずに自動的に処理する拡張を追加します。
BEA WebLogic Server の SDK 1.4.1 セキュリティのサポートにより、アプリケーションの開発者は、Sun Microsystems のセキュリティ領域の最新の強化拡張と開発を利用できます。このため、企業投資を主に Java プログラミング技術に傾注できます。定義され、文書化された Java 標準に従うことで、WebLogic Server のセキュリティ サポートでは Java 開発者に対する共通の基準が確立されます。WebLogic Server によって提供される新技術は、SDK 1.4.1 のサポートに基づいています。
WebLogic Server は、以下の SDK 1.4.1 セキュリティ パッケージに準拠し、それらのパッケージをサポートしています。
JSSE は、SSL と TLS v1 プロトコルをサポートおよび実装し、それらのプロトコルの機能をプログラムで利用可能にするパッケージのセットです。WebLogic Server では、WebLogic Server クライアント、および他のサーバとの間で転送されるデータを暗号化するために、セキュア ソケット レイヤ (SSL) がサポートされています。
JSSE は SSL 機能のクラスのコア セットを提供し、Certicom などの企業はそれらのクラスに対する拡張を提供します。WebLogic Server では、SSL の実装に Certicom JSSE 拡張を使用します。
JAAS は、ユーザベースの認証およびアクセス制御のためのフレームワークを提供するパッケージのセットです。 WebLogic Server では、JAAS の認証用クラスだけを使用します。
JAAS の詳細については、「JAAS (Java Authentication and Authorization Service)」を参照してください。
Java セキュリティ マネージャは、Sun Microsystems, Inc. によって開発された、Java 仮想マシン (JVM) のセキュリティ マネージャです。セキュリティ マネージャは、Java API と連携し java.lang.SecurityManager クラスを通じてセキュリティ境界を定義します。SecurityManager クラスは、プログラマが各自の Java アプリケーション用のカスタム セキュリティ ポリシーを確立することを可能にします。
Java セキュリティ マネージャと WebLogic Server を一緒に使用すると、JVM 内で実行されている WebLogic リソースのセキュリティを強化できます。WebLogic Server での Java セキュリティ マネージャを使用した WebLogic リソースの保護は、省略可能なセキュリティ手順です。
Java セキュリティ マネージャを使用すると、WebLogic リソースを保護するために、以下のセキュリティ タスクを行うことができます。
weblogic.policy ファイルの修正これらのタスクに対する Java セキュリティ マネージャの使用方法の詳細については、『WebLogic Security プログラマーズ ガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。
Sun Microsystems, Inc. によって開発された、これらのセキュリティ API は、Java プラットフォーム向けの暗号機能へのアクセスおよび暗号機能の開発と、暗号、鍵の生成と照合、および Message Authentication Code (MAC) アルゴリズムの実装の開発に使用するフレームワークを提供します。
WebLogic Server ではこれらのセキュリティ API が完全にサポートされています。
WebLogic Server では、IIOP (Internet Inter-ORB) (GIOP バージョン 1.2) および CORBA CSIv2 (Common Secure Interoperability version 2) 仕様に基づいた EJB (Enterprise JavaBean) 相互運用性プロトコルがサポートされています。WebLogic Server で CSIv2 をサポートすることにより、以下のことが可能になります。
注意 : WebLogic Server における CSIv2 実装は、J2EE CTS (Compatibility Test Suite) 適合性テストに合格しています。
CSIv2 実装への外部インタフェースは、CORBA オブジェクトのユーザ名とパスワードを取得する JAAS LoginModule です。JAAS LoginModule は、WebLogic Java クライアント、あるいは別の J2EE アプリケーション サーバに対するクライアントの役目をする WebLogic Server インスタンスで使用することができます。 CSIv2 サポート用の JAAS LoginModule は UsernamePasswordLoginModule という名前で、weblogic.security.auth.login パッケージに格納されています。
注意 : WebLogic Server クラスタ環境における CSIv2 サポート用のロード バランシングに関する情報については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サーバ アフィニティと CSIv2 を使用した IIOP クライアント認証」を参照してください。
|
|
|