|
|
|
|
|
|
| | | |
この章では、WebLogic Server のセキュリティに関する以下の基礎概念について説明します。
リソースとは、イベント、サーブレット、JDBC 接続プール、JMS の送り先、JNDI コンテキスト、接続、ソケット、ファイル、およびデータベースなどのエンタープライズ アプリケーションとそのリソースといった WebLogic Server からアクセス可能なエンティティのことです。
WebLogic Server で保護するリソースごとに、以下の項目を指定しなければなりません。
詳細については、「セキュリティの管理」を参照してください。
セキュリティ レルムとは、ユーザ、グループ、および ACL を論理的に分類したものです。WebLogic Server のリソースは、1 つのセキュリティ レルムに属し、そのレルム内の 1 つの ACL によって保護されます。ユーザはセキュリティ レルムで定義されていないと、そのセキュリティ レルムに属するリソースにアクセスできません。ユーザが特定の WebLogic Server リソースにアクセスしようとした場合、WebLogic Server は、関連レルム内で割り当てられている ACL とパーミッションをチェックして、ユーザを認証し、そのリソースに対する認可を持っているかを調べます。 図 2-1 は、WebLogic Server でのレルムの仕組みを示しています。
図2-1 WebLogic Server レルム内のユーザ、グループ、および ACL
WebLogic Server のデフォルトのセキュリティ レルムはファイル レルムです。WebLogic Server が起動すると、WebLogic Server の Administration Console で定義されたプロパティに基づいて、ファイル レルムがユーザ、グループ、および ACL オブジェクトを作成し、fileRealm.properties ファイルに保存します。
注意: ファイル レルムは、10,000 以下のユーザを対象としています。ユーザ数が 10,000 より多い場合は、代替セキュリティ レルムを使用することをお勧めします。
また、WebLogic Server は、特殊なセキュリティ状況に対応する必要のある開発者に対するサポートも提供しています。WebLogic Server では、代替セキュリティ レルムをインストールするか、またはカスタム セキュリティ レルムを作成することで、ファイル レルム以外のセキュリティ レルムを使用できます。代替セキュリティ レルムは、WebLogic Server がレルムに関して要求する認証および認可処理をサポートします。
レルムのコンフィグレーションには、次の 2 種類があります。
後者のコンフィグレーションでは、代替セキュリティ レルムまたはカスタム セキュリティ レルムは、プライマリ レルムとして機能します。ファイル レルムはバックアップ レルムになります。WebLogic Server のプライマリおよびバックアップ レルムは相互に連携して、適切な認証および認可を持つクライアントのリクエストを遂行します。たとえば、LDAP セキュリティ レルムなどの代替セキュリティ レルムを使用する場合は、まず、そのレルム内でユーザが検索されます。ユーザがプライマリ レルム（この場合は LDAP セキュリティ レルム）内に存在しない場合は、バックアップ レルムでユーザが検索されます。
注意: 代替セキュリティ レルムまたはカスタム セキュリティ レルムを使用する場合は、キャッシング レルムをコンフィグレーションする必要があります。
デフォルトの使い方では、クライアントのリクエストは、キャッシング レルムを通じて WebLogic Server に送られます。キャッシング レルムは、リクエストをファイル レルムに転送して、認可および認証処理を行います。ファイル レルムがレルム ルックアップの結果（成功または失敗）を受け取ると、キャッシング レルムがこれらの結果を保存します。キャッシング レルムは、ユーザ、グループ、パーミッション、ACL、および認証ルックアップのキャッシュを別々に保持します。キャッシュの各タイプを選択して有効化したり、キャッシュするオブジェクトの数を設定したり、キャッシュしたオブジェクトの有効期間（秒単位）を指定したりできます。実際には、キャッシング レルムによって、認証および認可処理がより早く、しかも効率的に行われます。
代替セキュリティ レルムまたはカスタム セキュリティ レルムを使用する場合、キャッシング レルムはクライアントのリクエストを評価して、適切なセキュリティ レルムに委任し、結果をキャッシュして次のルックアップを高速化します。たとえば、認証処理だけをサポートする代替セキュリティ レルムを使用しているとします。WebLogic Server がクライアントのリクエストを受け取ると、キャッシング レルムは、認証を行うために代替セキュリティ レルムと、認可を行うためにファイル レルムとそれぞれ通信します。
図 2-2 は、WebLogic Server 環境で代替セキュリティ レルム、キャッシング レルム、およびファイル レルムが相互に連携して、ユーザの認証と認可を処理する仕組みを示しています。
図2-2 WebLogic Server 内の代替セキュリティ レルム、キャッシング レルム、およびファイル レルム
WebLogic Server では、以下の代替セキュリティ レルムが用意されています。
Lightweight Directory Access Protocol（LDAP）サーバを通して認証を行います。このレルムを使用すると、ユーザを 1 つの場所、LDAP ディレクトリで管理できます。LDAP セキュリティ レルムを使用すると、LDAP サーバがユーザとグループを認証します。WebLogic Server で SSL プロトコルを使用している場合、LDAP セキュリティ レルムは、デジタル証明書からユーザの共通名を取り出し、その名前を LDAP ディレクトリで検索します。LDAP セキュリティ レルムはデジタル証明書を確認せず、確認は SSL プロトコルによって行われます。
LDAP セキュリティ レルムでは、現在、Open LDAP、Netscape iPlanet、Microsoft Site Server、および Novell NDS がサポートされています。
注意: WebLogic Server のこのリリースでは、更新された LDAP セキュリティ レルムが用意されています。更新された LDAP セキュリティ レルムは、パフォーマンスが向上し、コンフィグレーションが容易になりました。これらの機能を利用するために、更新された LDAP セキュリティ レルムにアップグレードすることをお勧めします。ただし、旧バージョンの LDAP セキュリティ レルムもまだ使用できます。詳細については、「セキュリティの管理」を参照してください。
Windows NT のアカウント情報を使用して、ユーザを認証します。Windows NT で定義したユーザおよびグループは、WebLogic Server で使用できます。Administration Console を使用してこのレルムを表示することはできますが、ユーザとグループを定義するには、Windows NT に付属の機能を使用しなければなりません。
ネイティブ プログラム、wlauth を実行し、UNIX ログイン ID とパスワードを使用して、ユーザとグループを認証します。UNIX セキュリティ レルムは、Solaris および Linux プラットフォームでのみサポートされています。wlauth では、プラグイン可能な認証モデル（PAM）を使用します。PAM を使用すると、認証サービスを使用する別のアプリケーションに変更せずに、このサービスを UNIX プラットフォーム内でコンフィグレーションできます。Administration Console を使用してこのレルムを表示することはできますが、ユーザとグループを定義するには、UNIX で提供されている機能を使用しなければなりません。
ユーザ、グループ、および ACL をデータベースから読み込みます。RDBMS セキュリティ レルムは、WebLogic Server 向けの認証および認可サービスを提供するカスタム レルムの実装例として用意されています。
詳細については、「セキュリティの管理」の以下の節を参照してください。
ユーザとは、アプリケーションのエンド ユーザ、クライアント アプリケーション、他の WebLogic Server など、WebLogic Server を使用するエンティティのことです。
ユーザが WebLogic Server にアクセスしようとする場合、ユーザは、プログラムを通じてユーザ名と資格（パスワードまたはデジタル証明書）を WebLogic Server に提示します。WebLogic Server がユーザ名と資格に基づいてユーザの ID を確認できた場合、WebLogic Server はユーザの代わりにコードを実行するスレッドをそのユーザに関連付けます。ただし、スレッドがコードの実行を始める前に、WebLogic Server は適切な ACL をチェックして、ユーザが処理を続行するために必要なパーミッションを持っていることを確認します。
WebLogic Server レルムでユーザを定義する場合は、そのユーザのパスワードも定義します。ユーザ名とパスワードは以前、WebLogic Server セキュリティ レルムにクリア テキストで保存されていました。現在、WebLogic Server では、すべてのパスワードがハッシュ化されています。クライアントのリクエストを受け取ると、WebLogic Server はクライアントが提示するパスワードをハッシュ化して、ハッシュ化済みパスワードと一致するかどうか比較します。
詳細については、「セキュリティの管理」の以下の節を参照してください。
グループとは、論理的に整理したユーザの集合のことです。グループを管理する方が、多くのユーザを個々に管理するよりも効率的です。たとえば、管理者は、グループを指定することで 50 ユーザのパーミッションを一度に指定することができます。一般に、グループ メンバーどうしは何らかの共通点を持っています。たとえば、職務によって WebLogic Server のリソースへのアクセス レベルが異なるため、企業の販売スタッフを、販売員と販売マネージャという 2 つのグループに分けることができます。
WebLogic Server をコンフィグレーションして、ユーザをグループに割り当てることができます。各グループは、メンバー ユーザによるリソースへのアクセスを管理する共通のパーミッション セットを共有します。ユーザのリストが許可されていれば、グループ名とユーザ名を混合することができます。
ユーザは、個人ユーザとしてもグループ メンバーとしても定義できます。個々のアクセス パーミッションは、グループ メンバーのパーミッションをオーバーライドします。WebLogic Server は、最初にグループを検索してユーザがグループのメンバーになっているかどうかを調べてから、定義済みユーザのリストの中でユーザを検索することで、各ユーザを評価します。
詳細については、「セキュリティの管理」の「グループの定義」を参照してください。
パーミッションは、リソースにアクセスするために必要な特権を表します。システム管理者は、リソースのアクセスに必要なパーミッションを持つユーザおよびグループのリストを作成することで、リソースを保護します。こうしたリストは、アクセス制御リスト（ACL）と呼ばれます。ACL と ACL によってパーミッションを付与する機能はリソース固有です。たとえば、適切なパーミッションを持つユーザであれば、ファイルの読み取り、書き込み、送信、および受信、サーブレットのロード、ライブラリへのリンクを行うことができます。
ACL ファイルは、それぞれが特定のユーザまたはグループを対象とする一連のパーミッションを格納する AclEntry から構成されます。
WebLogic Server は、Java Development Kit（JDK）1.1 で配布される JavaSoft ACL 標準を利用して、Java のセキュリティ フレームワークを拡張し、エンタープライズ レベルでの実用性を持たせています。WebLogic Server の ACL は、java.security.acl パッケージに基づいて実装されています。WebLogic Server の ACL はオープンスタンダードに準拠しているので、独自のソリューションにとらわれません。
パーミッションを設定できる WebLogic Server のリソースは以下のとおりです。
注意: EJB および Web アプリケーションへのアクセスは、ACL で制御するのではありません。それよりも、デプロイメント記述子のなかのセキュリティ要素を使用して、特定の EJB または Web アプリケーションへのアクセスを定義します。
詳細については、「セキュリティの管理」の「ACL の定義」を参照してください。
EJB セキュリティの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。
Web アプリケーション セキュリティの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
SSL プロトコルは、ネットワーク経由で接続された、複数のアプリケーションにセキュリティを提供します。具体的には、SSL プロトコルは以下のものを提供します。
SSL プロトコルを使用する場合、対象は常に発信元に対して自身を認証します。対象が要求した場合は、発信元が自身を対象に対して認証することもあります。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。SSL 接続はデジタル証明書をやりとりするアプリケーション間のハンドシェークで始まり、使用する暗号化アルゴリズムの取り決め、そのセッションの残りで使用する暗号キーの生成と続きます。
SSL プロトコルは、以下のセキュリティ機能を提供します。
Web ブラウザを使って WebLogic Server と通信する場合は、Hypertext Transfer Protocol with SSL（HTTPS）を利用して、ネットワーク通信の安全性を確保できます。
SSL プロトコルは、IP ベースのプロトコル上をトンネリングされます。トンネリングとは、各 SSL レコードをカプセル化し、別のプロトコル上でレコードを送信するために必要なヘッダと一緒にパッケージ化することです。SSL を使用していることは、WebLogic Server の場所を指定するための URL のプロトコル方式で表されます。
https://myserver.com/mypage.html
WebLogic Server では、SSL3 をサポートする Web ブラウザで HTTPS を使用できます。WebLogic Server の Java 仮想マシン（JVM）では、現在、HTTPS プロトコル アダプタがサポートされていません。したがって、WebLogic Server は、Web ブラウザでの SSL 実装に依存します。
t3s://myserver.com:7002/mypage.html
WebLogic Server 内で動作する Java クライアントは、他の WebLogic Server に T3S 接続するか、または Web サーバや安全なプロキシ サーバなど SSL プロトコルをサポートする他サーバに HTTPS 接続します。
WebLogic Server は、輸出向けと米国内向けのどちらの長さの SSL でも使用できます。
標準の WebLogic Server 配布キットは、輸出向けの長さの SSL だけをサポートします。米国内向けバージョンについては、BEA の販売代理店を通じてお求めください。米国政府は、2000 年初めに暗号化ソフトウェアの輸出に関する規制を緩和したので、米国内向けバージョンの WebLogic Server はほとんどの国でご使用いただけます。
インストール時に、使用する SSL プロトコルの長さを選択する手順があります。暗号の強度が高いので、米国内向け WebLogic Server 配布キットをお勧めします。輸出向け WebLogic Server 配布キットを使って証明書署名リクエスト（CSR）を生成する場合は、高レベル接続に対応できないので、米国内向けレベルの証明書を提示するクライアントを認証できません。
WebLogic Server が提供する SSL プロトコルの実装は、pure-Java 実装です。Solaris、Windows NT、および IBM AIX プラットフォームでの SSL 処理によっては、ネイティブ ライブラリを使う方がパフォーマンスが向上します。SSL プロトコルでこうしたネイティブ Java ライブラリを使うよう要求するには、Administration Console を使います。
詳細については、「セキュリティの管理」の「SSL プロトコルのコンフィグレーション」を参照してください。
WebLogic Server ユーザが、保護されているWebLogic Server リソースへのアクセスを要求する場合、必ず認証を受けなければなりません。このため、各ユーザは資格（ユーザ名/パスワードの組み合わせまたはデジタル証明書）を WebLogic Server に提示する必要があります。WebLogic Server では、以下のタイプの認証メカニズムがサポートされています。
SSL（または HTTPS）プロトコルを使用すると、パスワード認証にさらに高度なレベルのセキュリティを提供できます。SSL プロトコルは、クライアントと WebLogic Server との間で転送されるデータを暗号化するので、ユーザ ID とパスワードはクリア テキストでは転送されません。したがって、WebLogic Server は、ユーザの ID およびパスワードの機密性を保持したままユーザを認証できます。
相互認証を用いることもできます。この場合、WebLogic Server は自身を認証するだけでなく、要求側のクライアントに対しても認証を要求します。クライアントは、信頼された認証局が発行したデジタル証明書を提出するよう要求されます。相互認証は、アクセスを許可する対象を信頼されたクライアントに制限する場合に便利です。たとえば、管理者が提供したデジタル証明書を持つクライアントだけにアクセスを制限すると便利な場合があります。
詳細については、「セキュリティの管理」の以下の節を参照してください。
デジタル証明書とは、インターネットなどのネットワークを経由して、プリンシパルおよびエンティティのユニークな ID を確認するための電子的なドキュメントのことです。デジタル証明書は、認証局として知られる信頼された第三者によって確認されたユーザまたはエンティティの ID を、特定の公開鍵に安全にバインドします。公開鍵とプライベート キー（秘密鍵）を組み合わせることで、デジタル証明書のオーナにユニークな ID が提供されます。
デジタル証明書を使用すると、特定の公開鍵が実際に特定のユーザまたはエンティティに属しているかどうかを確認できます。デジタル証明書の受信側は、証明書内の公開鍵を使用して、デジタル署名が対応するプライベート キーで作成されたものかどうかを確認します。こうした確認が終わると、この推論のチェーンによって、対応するプライベート キーの所有者がデジタル証明書に名前のある主体であること、そしてそのデジタル署名を作成したのがその主体であることを確認できます。
一般に、デジタル証明書には以下のようにさまざまな情報が入っています。
最も広く使われているデジタル証明書のフォーマットは、ITU-T X.509 国際標準で定義されているものです。X.509 標準に準拠していればどのアプリケーションを使っても、デジタル証明書を読み書きできます。WebLogic Server の公開鍵インフラストラクチャ（PKI）では、X.509 バージョン 3 または X.509v3 に準拠したデジタル証明書が認識されます。Verisign や Entrust などの認証局から証明書を取得することをお勧めします。
WebLogic Server では、X.509 標準によって提供される拡張子がサポートされていますが、weblogic.security.X509 クラスには特定のデジタル証明書で使用される拡張子に関する情報を提供するアクセサが用意されていません。その情報を入手するには、weblogic.security.X509 オブジェクトを java.security.cert.X509Certificate オブジェクトに変換します。次のコード例には、この変換を行うコードが含まれています。
X509[] wlCerts=...
X509Certificate [] javaCerts = new X509Certificate[wlCerts.length];
try{
CertificateFactory cf =
java.security.cert.CertificateFactory.getInstance("X.509");
for(int i=0; i<wlCerts.length; i++){
ByteArrayOutputStream bos = new ByteArrayOutputStream();
wlcerts[i].output(bos);
ByteArrayInputStream bis = new
ByteArrayInputStream(bos.toByteArray());
javaCerts[i] = (X509Certificate)cf.generateCertificate(bis);
}
}
詳細については、「セキュリティの管理」の「SSL プロトコルのコンフィグレーション」を参照してください。
デジタル証明書は、認証局によって発行されます。デジタル証明書および公開鍵の発行先の ID を保証する信頼された第三者組織または企業はすべて、認証局になることができます。認証局は、デジタル証明書を作成する際に、証明書が改ざんされればわかるようにプライベート キーを使って署名します。認証局は、署名したデジタル証明書を要求主体に返します。
主体は、認証局の公開鍵を使って発行認証局の署名を確認します。認証局の公開鍵は、低レベル認証局の公開鍵の妥当性を保証する高レベル認証局から発行されたデジタル証明書を提供することで利用できるようになります。この方式によって、認証局の階層が構築されます。この階層は、最終的に、ルート キーと呼ばれる自己署名デジタル証明書にたどり着きます。
暗号化されたメッセージの受信側は、受信側がすでに信頼性を確認済みで該当認証局よりも高レベルの認証局が署名し、該当認証局の公開鍵が入ったデジタル証明書を持っている場合は、認証局のプライベート キーを再帰的に信頼します。この点では、デジタル証明書はデジタルの信頼関係の踏み台です。結局、信頼する必要があるのは、ごく少数の最上位認証局の公開鍵だけです。デジタル証明書のチェーンを通じて、多数のユーザのデジタル署名の信頼を確立できます。
通信中のエンティティの ID は、このようにしてデジタル署名によって確立できますが、デジタル署名による信頼は、信頼性を確認するための公開鍵の範囲にとどまります。
詳細については、「セキュリティの管理」の「SSL プロトコルのコンフィグレーション」を参照してください。
公開鍵（または非対称鍵）アルゴリズムは、数学的には互いに関連を持ちながらも異なる 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 回の暗号化処理に使います。
RC4 は、サイズが 40 〜 128 ビットの鍵を使用する可変キー サイズ ブロック暗号です。DES よりも処理が高速で、キー サイズを 40 ビットにして輸出可能です。米国企業の海外子会社および海外支社には、56 ビットのキー サイズが許可されています。WebLogic Server PKI によってキー長が 128 ビットに制限されていますが、米国では、事実上キー長の制限なしに RC4 を使用できます。
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 でサポートされている暗号スイートは、 表 2-1 のとおりです。
config.xml ファイルで定義されている暗号スイートの強度がライセンスで指定されている強度を超える場合は、ライセンスで指定されている強度が使用されます。たとえば、ライセンスが輸出向け強度であるにもかかわらず、米国内向け強度の暗号スイートを使うよう config.xml で定義した場合は、米国内向け強度の暗号スイートは拒否されて、輸出向け強度の暗号スイートが使用されます。
|
|
|