|
|
|
|
|
|
| | | |
以下の節では、WebLogic Server でセキュリティを実装する方法について説明します。
WebLogic Server のデプロイメントのセキュリティは、主にそのデプロイメントに合わせたセキュリティ ポリシーを定義する属性をコンフィグレーションすることで実装します。WebLogic Server には、デプロイメントのセキュリティ ポリシーを定義するための Administration Console が用意されています。Administration Console を使用して、デプロイメントの次の要素にセキュリティ固有の値を指定します。
セキュリティ機能は互いに関連しているので、セキュリティをコンフィグレーションする場合に何から始めるべきか判断しにくいものです。実際、WebLogic Server のデプロイメントのセキュリティを定義する場合には、同じ作業を繰り返すこともあります。手順は 1 通りではありませんが、次の手順に従うことをお勧めします。
system ユーザのパスワードを変更して、WebLogic Server のデプロイメントを保護します。
システム パスワードの変更を参照してください。
WebLogic Server のセキュリティ機能の詳細については、「WebLogic Security の概要」と「セキュリティの基礎概念」を参照してください。
注意: この節のコンフィグレーション手順はすべて Administration Console を使用して行います。
セキュリティ ロールの WebLogic EJB への割り当てについては、「WebLogic Server 6.1 デプロイメント プロパティ」を参照してください。
WebLogic Web アプリケーションでのセキュリティの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
インストール中に、system ユーザのパスワードを指定します。指定されたパスワードは、WebLogic Server の system ユーザに関連付けられ、\wlserver6.1\config\domain ディレクトリの fileRealm.properties ファイルに保存されます。domain は、インストール時に WebLogic 管理ドメイン名として指定された名前です。指定されたパスワードは、ドメインの管理サーバと、その管理サーバに関連付けられているすべての管理対象サーバに対応しています。
注意: system ユーザは、WebLogic Server を起動できる唯一のユーザ アカウントです。
system ユーザのパスワードは、WebLogic Server がハッシュを適用するときに暗号化され、さらに保護されます。セキュリティを強化するため、インストール時に設定したシステム パスワードを頻繁に変更することをお勧めします。WebLogic Server の各デプロイメントでは、ユニークなパスワードが必要です。
システム パスワードを変更するには、次の手順に従います。
system と入力します。
あるドメインの管理サーバと管理対象サーバを使用する場合、管理対象サーバは常にそのドメインの管理サーバのパスワードを使用しなければなりません。管理サーバのパスワードは、常に Administration Console を使用して変更してください。パスワードを変更したら、そのドメイン内のすべてのサーバを再起動します。次の手順に従って操作します。
WebLogic パスワードの機密性を維持することは、WebLogic Server のデプロイメントとデータの安全性を確保する上で極めて重要です。デプロイメントとデータを保護するために、WebLogic Server のパスワードの機密性を維持することをお勧めします。
この節では、WebLogic Server デプロイメントのセキュリティ レルムをコンフィグレーションする方法について説明します。セキュリティ レルムの概要と WebLogic Server での使用方法については、『WebLogic Security プログラマーズ ガイド』の「セキュリティ レルム」を参照してください。以下の節では、セキュリティ レルムの指定について説明します。
ファイル レルムのコンフィグレーション
WebLogic Server のセキュリティ レルムは、デフォルトでファイル レルムです。ファイル レルムを使用する前に、ファイル レルムの使用を管理する属性を定義する必要があります。これらの属性は、Administration Console の [セキュリティ] ウィンドウの [ファイル レルム] タブで設定します。
次の表では、[ファイル レルム] タブの各属性について説明します。
表14-1 ファイル レルムの属性
ユーザ、グループ、および ACL のキャッシュをクリアするには、[Manage Caching Realm] ボタンを使用します。
警告: fileRealm.properties ファイルが壊れたら、WebLogic Server のセキュリティ情報を再コンフィグレーションしなければなりません。WebLogic Server は、fileRealm.properties ファイルがないと起動できません。
fileRealm.properties ファイルには、WebLogic Server を起動するためのデフォルト ACL が含まれています。カスタム セキュリティ レルムは起動シーケンスでは呼び出されないので、カスタム セキュリティ レルムを記述する場合でも、WebLogic Server を起動するために fileRealm.properties ファイルは必要となります。
したがって、次の手順を実行することをお勧めします。
fileRealm.properties ファイルのバックアップを作成し、安全な場所に保管します。
WebLogic Server デプロイメントの管理者は読み書き特権を持ち、その他のユーザは何の特権も持たないように、fileRealm.properties ファイルにパーミッションを設定します。
注意: また、ファイル レルム用の SerializedSystemIni.dat ファイルのバックアップも作成する必要があります。SerializedSystemIni.dat ファイルの詳細については、「
パスワードの保護」を参照してください。
ファイル レルムの代わりに WebLogic Server で提供される代替セキュリティ レルムまたはカスタム セキュリティ レルムを使用する場合は、必要なレルムに合わせて属性を設定し、WebLogic Server を再起動します。代替セキュリティ レルムを使用する場合は、キャッシング レルムを有効にする必要があります。
WebLogic Server のセキュリティ レルムの詳細については、「セキュリティ レルム」を参照してください。
キャッシング レルムはファイル レルム、代替セキュリティ レルム、またはカスタム セキュリティ レルムと連携し、適切な認証および認可を得たクライアントのリクエストを遂行します。キャッシング レルムは、成功したレルム ルックアップと失敗したレルム ルックアップの両方の結果を格納します。キャッシング レルムは、ユーザ、グループ、パーミッション、ACL、および認証リクエストのキャッシュを別々に管理します。キャッシング レルムによって、ルックアップがキャッシュされ、ほかのセキュリティ レルムへの呼び出し数が減るので、WebLogic Server のパフォーマンスが向上します。WebLogic Server のセキュリティ レルムの詳細については、「セキュリティ レルム」を参照してください。
キャッシング レルムは、WebLogic Server のインストール時に自動的にインストールされます。キャッシュはその他のセキュリティ レルムに権限を委託するよう設定されますが、キャッシュは有効化されていません。Administration Console を使用して、キャッシュを有効化する必要があります。代替セキュリティ レルムまたはカスタム セキュリティ レルムを使用する場合は、キャッシング レルムをコンフィグレーションして有効にする必要があります。
キャッシュを有効化すると、キャッシング レルムによって、レルム ルックアップの結果がキャッシュに保存されます。ルックアップの結果は、存続時間（TTL）属性に定義された秒数が経過する（ルックアップの結果の有効期限が切れる）か、またはキャッシュがいっぱいになるまで、キャッシュ内に残ります。キャッシュがいっぱいになると、ルックアップの結果はキャッシュ内で最も古い結果と置き換えられます。TTL 属性によって、キャッシュされたオブジェクトの有効期間が決定されます。これらの属性に設定する値が大きいほど、キャッシング レルムが二次セキュリティ レルムを呼び出す回数が減ります。呼び出し回数が減ると、パフォーマンスは向上します。パフォーマンスが向上する代わりに、基のセキュリティ レルムへの変更は、キャッシュされたオブジェクトの有効期間が切れるまで認識されません。
注意: セキュリティ レルムからオブジェクトを取得した場合、オブジェクトはオブジェクトのスナップショットを反映しています。オブジェクトを更新するには、そのオブジェクトの get() メソッドをもう一度呼び出します。たとえば、グループのメンバシップは、getGroup() メソッドを呼び出してセキュリティ レルムからグループを取得したときに設定されます。グループのメンバを更新するには、getGroup() メソッドをもう一度呼び出さなければなりません。
デフォルトでは、キャッシング レルムは、代替セキュリティ レルムが大文字/小文字を区別することを前提にして処理します。大文字/小文字を区別するセキュリティ レルムでは、たとえば bill というユーザ名のオーナと Bill というユーザ名のオーナは、別々のユーザとして扱われます。大文字/小文字を区別しないセキュリティ レルムの例として、Windows NT セキュリティ レルムと LDAP セキュリティ レルムが挙げられます。大文字/小文字を区別しないセキュリティ レルムを使用する場合は、[キャッシュで大文字/小文字を区別] 属性を無効化しなければなりません。この属性を設定すると、キャッシング レルムでは、大文字/小文字を区別して比較した場合に WebLogic Server がセキュリティ レルムの正しい結果を返すように、ユーザ名が小文字に変換されます。大文字/小文字を区別するセキュリティ レルムのユーザまたはグループを定義したり参照したりする場合には、ユーザ名を小文字で入力します。
キャッシング レルムをコンフィグレーションするには、次の操作を行います。
次の表では、[一般] タブで設定する属性について説明します。
表14-2 [一般] タブのキャッシング レルム属性
次の表では、[ACL] タブで設定する属性について説明します。
次の表では、[認証] タブで設定する属性について説明します。
次の表では、[グループ] タブで設定する属性について説明します。
次の表では、[ユーザ] タブで設定する属性について説明します。
次の表では、[パーミッション] タブの各属性について説明します。
LDAP セキュリティ レルムでは、Lightweight Directory Access Protocol（LDAP）サーバを使用して認証を行います。このサーバを使用すると、組織内のすべてのユーザを LDAP ディレクトリだけで管理できます。LDAP セキュリティ レルムは、Open LDAP、Netscape iPlanet、Microsoft Site Server、および Novell NDS をサポートしています。
このリリースの WebLogic Server では、LDAP セキュリティ レルムを以下の 2 つのバージョンから選択できます。
getUsers() または getGroups() をサポートしていません。これらのリクエストを遂行するためにメモリを割り当てるとサービス拒否攻撃を受ける可能性があるからです。これらの機能を使用する場合、LDAP レルム V1 を使用することをお勧めします。Windows 2000 を実行している場合は、LDAP レルム V2 を使用し、Windows 2000 ユーザおよびグループ ストアに照らして認証することをお勧めします。
注意: LDAP レルム V1 を使用する場合は、Administration Console を使用して LDAP ディレクトリ サーバに格納されているユーザおよびグループのメンバーを表示できます。ただし、LDAP レルム V2 を使用する場合は、LDAP ディレクトリ サーバに格納されているグループのみ Administration Console を使用して表示できます。
ユーザまたはグループの追加や削除、あるいはグループのメンバーの追加など、ユーザおよびグループを管理するためには、LDAP サーバで利用可能な管理ツールを使用する必要があります。LDAP ディレクトリ ストアで変更を行った場合は、ユーザ キャッシュおよびグループ キャッシュをリセットすると、Administration Console ですぐにその変更を表示できます。
LDAP セキュリティ レルムのパフォーマンスを向上させるためのヒントを次に示します。
ldaprealm.props ファイルでフィルタを使用して、LDAP サーバから取得する結果セットをより具体的に絞り込みます（LDAP レルム V2 のみ）。
LDAP セキュリティ レルムのコンフィグレーションでは、LDAP サーバと通信するために LDAP セキュリティ レルムを WebLogic Server で有効化する属性と、ユーザおよびグループを LDAP ディレクトリに保存する方法を指定する属性を定義します。LDAP ツリーおよびスキーマは、LDAP サーバごとに異なります。したがって、LDAP レルム V2 では、サポートされている LDAP サーバのデフォルト属性を定義するテンプレートのセットが提供されます。
LDAP セキュリティ レルム使用時の制限
LDAP セキュリティ レルムには以下の制限があります。
Administrators という空のデフォルト グループを持つ NTGroups というデフォルトの組織単位があります。デフォルトでは、WebLogic Server でも、System（WebLogic Server が起動されるユーザ）というメンバーが含まれる Administrators というグループが提供されます。Microsoft Site Server でデフォルトを使用し、デフォルト組織単位の下で独自のグループを作成し始めると、WebLogic Server は起動しなくなります。LDAP セキュリティ レルムを使用して WebLogic Server を起動するためには、LDAP ディレクトリで独自のユニークな組織単位を作成し、その組織単位の下で WebLogic Server デプロイメントのグループを作成する必要があります。
getGroups() メソッドを実行すると、Open LDAP Server に問題が発生します。 この問題は、Open LDAP におけるキャッシングのバグが原因です。
LDAP ディレクトリ内でのユーザおよびグループの位置
LDAP セキュリティ レルムは、そのセキュリティ レルムで使用される LDAP ディレクトリのどこにユーザとグループが格納されているのかを知る必要があります。そのためには、ユーザとグループが存在する LDAP ディレクトリの識別名（DN）を指定します。
LDAP では、DN はリーフ ノードから始まり、ルート ノードに向かいます。 たとえば、次のようになります。
root
|
|
|
o=acme.com
|
|
|
ou=Groups
このブランチの DN は、 ou=Groups, o=acme.com として指定されます。
LDAP レルム V1 では、DN は、セキュリティ レルムをコンフィグレーションする際に、 GroupDN 属性と UserDN 属性を介して指定します。ただし、DN を反対方向に指定する必要があります。たとえば、サンプル DN は、groupDN="o=acme.com, ou=Groups" として指定されます。
LDAP レルム V2 では、DN は、 user.dn プロパティと group.dn プロパティを CustomRealm MBean の Configuration 属性に追加して行います。LDAP レルム V1 とは異なり、DN を反対方向に指定する必要はありません。たとえば、 LDAP レルム V2 のuser.dn プロパティと group.dn プロパティは次のようになります。
ConfigurationData="..., group.dn=ou=Groups, o=acme.com, ..."
LDAP レルム V1 と LDAP レルム V2 を切り替えるときにカスタマがよく犯すエラーは、反対方向の DN をコピーしてしまい、LDAP セキュリティ レルムが動作を停止してしまうことです。LDAP レルム V1 から LDAP レルム V2 に移行するときには、 DN の仕様をチェックしてください。
LDAP レルム V1 のコンフィグレーション
ファイル レルムの代わりに LDAP セキュリティ レルム V1 を使用するには、次の操作を行います。
LDAP セキュリティ レルムを実装するクラスの名前が表示されます。
次の表では、[LDAP レルム V1（非推奨）] タブで設定する属性について説明します。
次の表では、[ユーザ] タブで設定する属性について説明します。
次の表では、[グループ] タブで設定する属性について説明します。
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューから LDAP レルム を選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム（この場合は LDAP レルム V1）の関連付けを定義します。
キャッシング レルムは、LDAP ディレクトリでのルックアップの回数を減らすためにユーザとグループを内部にキャッシュします。ユーザ キャッシュおよびグループ キャッシュ内の各オブジェクトには、キャッシング レルムをコンフィグレーションするときに設定する TTL 属性があります。LDAP ディレクトリ内で変更を加えた場合、キャッシュされているオブジェクトが有効期限切れになるか、フラッシュされるまで、それらの変更は LDAP セキュリティ レルムに反映されません。デフォルトの TTL は、ルックアップが失敗した場合に 60 秒、成功した場合に 10 秒です。ユーザ キャッシュとグループ キャッシュの TTL 属性を変更しないかぎり、LDAP ディレクトリ内の変更は 60 秒後に LDAP セキュリティ レルムに反映されます。
LDAP セキュリティ レルムで getUser() を呼び出すなどサーバ側コードで LDAP セキュリティ レルム内のルックアップを実行した場合、レルムから返されるオブジェクトは、コードで解放されるまで解放されません。したがって、WebLogic Server によって認証されたユーザは、LDAP ディレクトリから削除された場合でも、接続が持続しているかぎり有効なままです。
LDAP レルム V2 のコンフィグレーション
LDAP レルム V2 のコンフィグレーションには、セキュリティ レルムと LDAP サーバとの通信を可能にするための属性と、LDAP ディレクトリにおけるユーザおよびグループの格納場所を記述する属性を定義することが必要になります。LDAP ツリーおよびスキーマは、LDAP サーバごとに異なります。WebLogic Server には、サポート対象の LDAP サーバ用のテンプレートが用意されています。これらのテンプレートでは、サポート対象の各 LDAP サーバでユーザとグループを表現するのに用いられるデフォルトのコンフィグレーション情報が指定されています。詳細については、 サポート対象 LDAP サーバ用テンプレートを参照してください。
LDAP セキュリティ レルム V2 をコンフィグレーションするには、使用する LDAP サーバに対応するテンプレートを選び、それを修正して具体的なコンフィグレーションの情報を指定します。
LDAP セキュリティ レルム V2 を使用するには、次の操作を行います。
選択した LDAP サーバのコンフィグレーション ウィンドウが表示されます。
server.host - LDAP サーバのホスト名
server.port - LDAP サーバのリスン ポート番号
useSSL - SSL を使用して LDAP サーバと WebLogic Server との通信を保護するかどうかを指定。SSL を使用するには、この値を true に設定する。
server.principal - WebLogic Server で LDAP サーバへの接続に使用される LDAP ユーザ
server.credential - WebLogic Server で LDAP サーバへの接続に使用される LDAP ユーザのパスワード
user.dn - ユーザが格納される LDAP ディレクトリ内ツリーの基本 DN (識別名)
user.filter - 指定した名前のユーザを探すための LDAP 検索フィルタ
group.dn - グループが格納される LDAP ディレクトリ内ツリーの基本 DN (識別名)
group.filter - 指定した名前のグループを探すための LDAP 検索フィルタ
membership.filter - 指定した名前のグループに属するメンバーを探すための LDAP 検索フィルタ
詳細については、 サポート対象 LDAP サーバ用テンプレートを参照してください。
注意: Microsoft Site Server 用の LDAP レルム V2 を使用する際には、 membership.search=true も併せて指定し、Microsoft Site Server で無効なユーザが認証されないように user.filter 値に以下を追加する必要があります。
user.filter=(&(sAMAccountName=%u)(objectclassname=user)
(!userAccountControl:1.2.840.113556.1.4.803:=2))
キャッシング レルムをコンフィグレーションする際には、[一般] タブの [基本レルム] 属性のプルダウン メニューから、defaultLDAPRealmforLDAPserver (たとえば、defaultLDAPRealmforOpenLDAPDirectoryServices) を選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム (ここでは LDAP レルム) との関連を定義します。
サポート対象 LDAP サーバ用テンプレート
LDAP レルム V2 でサポートされている LDAP サーバのコンフィグレーションに使用されるテンプレートを、 コード リスト 14-1 から コード リスト 14-4 に示します。
警告: 以下のコード例の各行は、実際には 1 行で入力する必要があります。これらのコードは、このマニュアルのページ設定に合わせて書式付けされており、そのために複数に分けて記載されている行もあります。
コード リスト 14-1 Netscape Directory Server 用のデフォルト テンプレート
<CustomRealmName="defaultLDAPRealmForNetscapeDirectoryServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=uid=admin,
ou=Administrators,ou=TopologyManagement,o=NetscapeRoot;
server.credential=*secret*;
user.dn=ou=people,o=beasys.com;
user.filter=(&(uid=%u)(objectclass=person));
group.dn=ou=groups,o=beasys.com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(uniquemember=%M)
(objectclass=groupofuniquenames));
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
コード リスト 14-2 Microsoft Site Server 用のデフォルト テンプレート
<CustomRealmName="defaultLDAPRealmForMicrosoftSiteServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Administrator,ou=Members,
o=ExampleMembershipDir;
server.credential=*secret*
user.dn=ou=Members, o=ExampleMembershipDir;
user.filter=(&(cn=%u)(objectclass=member)(!userAccountControl:1.2.840.113556.1.4.803:=2)));
group.dn=ou=Groups, o=ExampleMembershipDir;
group.filter=(&(cn=%g)(objectclass=mgroup));
membership.scope.depth=1;microsoft.membership.scope=sub;
membership.filter=(|(&(memberobject=%M)
(objectclass=memberof))(&(groupobject=%M)
(objectclass=groupmemberof)));
membership.search=true;
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
コード リスト 14-3 Novell Directory Services 用のデフォルト テンプレート
<CustomRealmName="defaultLDAPRealmForNovellDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Admin, DC=BEASYS
server.credential= *secret*;
user.dn=ou=people,o=example.com;
user.filter=(&(cn=%u)(objectclass=person));
group.dn=ou=groups,o=example.com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(member=%M)
(objectclass=groupofuniquenames));"
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
コード リスト 14-4 Open LDAP Directory Services 用のデフォルト テンプレート
<CustomRealmName="defaultLDAPRealmForOpenLDAPDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Manager, dc=example, dc=com;
server.credential= *secret*;
user.dn=ou=people, dc=example,dc=com;
user.filter=(&(uid=%u)(objectclass=person));
group.dn=ou=groups,dc=example,c=com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(uniquemember=%M) (objectclass=groupofuniquenames));"
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
WebLogic Server での Microsoft Active Directory の使用
WebLogic Server のデフォルト設定では、Microsoft Active Directory LDAP サーバはサポートされません。Microsoft Active Directory を WebLogic Server で使用するには、以下の手順を実行します。
選択した LDAP サーバのコンフィグレーション ウィンドウが表示されます。
server.host - LDAP サーバのホスト名
server.port - LDAP サーバのリスン ポート番号
useSSL - SSL を使用して LDAP サーバと WebLogic Server との通信を保護するかどうかを指定。SSL を使用するには、この値を true に設定する。
server.principal - WebLogic Server で LDAP サーバへの接続に使用される LDAP ユーザ
server.credential - WebLogic Server で LDAP サーバへの接続に使用される LDAP ユーザのパスワード
user.dn - ユーザが格納される LDAP ディレクトリ内ツリーの基本 DN (識別名)
user.filter - 指定した名前のユーザを探すための LDAP 検索フィルタ
group.dn - グループが格納される LDAP ディレクトリ内ツリーの基本 DN (識別名)
group.filter - 指定した名前のグループを探すための LDAP 検索フィルタ
membership.filter - 指定した名前のグループに属するメンバーを探すための LDAP 検索フィルタ
WebLogic Server 側では、LDAP サーバにバインドし、ユーザの DN とパスワードを渡すことで、認証を行います。たとえ、LDAP の userAccountControl 属性を ACCOUNTDISABLE に設定してユーザ アカウントを無効にしておいても、無効になったアカウントを無視するように user.filter 値を変更しておかなければ、認証は成功してしまいます。そこで、UF_ACCOUNTDISABLE ビットが設定されていないアカウントだけを返すように、user.filter 値を修正します。たとえば、以下のように指定します。
user.filter=(&(sAMAccountName=%u)(objectclassname=user)
(!userAccountControl:1.2.840.113556.1.4.803:=2))
group.filter 値を指定する際には、CN は CN=%G のように指定する必要があります。そうしないと、フィルタはグループのメンバを検索できません。
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューから defaultLDAPRealmforLDAPserver (たとえば、defaultLDAPRealmforOpenLDAPDirectoryServices) を選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム（この場合は LDAP レルム）の関連付けを定義します。
Windows NT セキュリティ レルムのコンフィグレーション
Windows NT セキュリティ レルムでは、Windows NT ドメイン向けに定義されたアカウント情報を使用して、ユーザとグループを認証します。Windows NT セキュリティ レルム内のユーザおよびグループは Administration Console で表示できますが、ユーザおよびグループを管理する場合は Windows NT の機能を使用しなければなりません。
Windows NT セキュリティ レルムでは、（ユーザとグループの）認証は行えますが、（ACL の）認可を行うことはできません。WebLogic Server が使用する filerealm.properties ファイルの ACL 情報を更新するには、ACL を変更した後に [セキュリティ] ノードの [一般] タブで [更新] ボタンをクリックします。ACL でグループを使用すれば、WebLogic Server の情報を更新する回数を減らすことができます。Windows NT グループのメンバを変更すると、WebLogic Server リソースへの個々のユーザのアクセスを動的に管理できます。
Windows NT セキュリティ レルムを使用して、Windows 2000 Active Directory プライマリ ドメイン コントローラに照らし合わせて認証することは可能です。ただし、ドメイン コントローラ自体ではなく、ドメインのメンバーとなっているマシンから認証を行う必要があります。Windows NT セキュリティ レルムを実行するマシンが別のドメインのメンバーの場合、ローカルのユーザおよびグループ ストアを認証する方法はありません。
Windows NT セキュリティ レルムは、プライマリ ドメイン コントローラ、Windows NT ドメインのメンバーとなっているマシン、またはその Windows NT ドメインのメンバーとなっており、相互に信頼されたドメインを使用するマシンで実行可能です。
Windows NT セキュリティ レルムを使用するには、次の操作を行います。
次の表では、[新しい NT Realm の作成] ウィンドウの [コンフィグレーション] タブで設定する属性について説明します。
|
属性 |
説明 |
|---|---|
|
[名前] |
AccountingRealm などの Windows NT セキュリティ レルムの名前。 |
|
[プライマリ ドメイン] |
Windows NT ドメイン向けのユーザとグループが定義されたコンピュータのホストおよびポート番号。複数のホストとポート番号を入力する場合は、カンマ区切りのリストを使用する。 |
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューから Windows NT セキュリティ レルムを選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム（この場合は Windows NT セキュリティ レルム）の関連付けを定義します。
次のコマンドを使用して、指定された Windows NT ユーザとして WebLogic Server を実行するための正しい特権を持っていることを確認します。
java weblogic.security.ntrealm.NTRealm username password
username と password は、WebLogic Server を実行する Windows NT アカウントのユーザ名とパスワードです。
このコマンドの出力によって、指定されたユーザ名とパスワードが適切に認証されたかどうかわかります。
|
コマンドの出力 |
意味 |
|---|---|
|
|
入力されたユーザ名とパスワードは正しく認証された。 |
|
|
入力されたユーザ名とパスワードは正しく認証されなかった。 |
テストの結果、WebLogic Server を実行するクライアントまたはユーザが Windows NT セキュリティ レルムを実行する特権を持っていないことがわかった場合、WebLogic Server を実行する Windows ユーザのパーミッション（権利と呼ばれる）を更新する必要があります。
Windows NT で権利を更新するには、次の手順に従います。
Windows 2000 で権利を更新するには、次の手順に従います。
Windows NT セキュリティ レルムを使用する場合に発生する Windows NT の一般的なエラーを以下に示します。
Windows NT のエラー コードについては、winerror.h ファイルで詳しく説明されています。
注意: UNIX セキュリティ レルムは、Solaris および Linux プラットフォーム上でのみ動作します。
UNIX セキュリティ レルムは小さなネイティブ プログラム（wlauth）を実行して、ユーザとグループを検索し、UNIX ログイン名とパスワードに基づいてユーザを認証します。wlauth プログラムは PAM（Pluggable Authentication Modules）を使用します。これにより、オペレーティング システムの認証サービスを、このサービスを使用するアプリケーションを変更することなくコンフィグレーションできます。
UNIX では、ユーザは以下のようにして、グループのメンバーとして定義されます。
etc/passwd 内のデフォルト グループに定義される。
etc/group エントリ内にある。UNIX セキュリティ レルムは、グループのメンバーを判断するこの方法のみをサポートします。
ACL を変更した後は、[セキュリティ] の [一般] タブで [更新] ボタンをクリックして、WebLogic Server が使用する filerealm.properties ファイルの情報を更新します。ACL でグループを使用すれば、WebLogic Server の情報を更新する回数を減らすことができます。UNIX グループのメンバを変更すると、WebLogic Server リソースへの個々のユーザのアクセスを動的に管理できます。
wlauth プログラムは、setuid root を実行します。wlauth プログラムの所有権とファイル属性を変更し、wlauth に合わせて PAM コンフィグレーション ファイルを設定するには、ルート パーミッションが必要です。
UNIX セキュリティ レルムの wlauth プログラムを設定するには、次の操作を行います。
wlauth ファイルを、WebLogic Server を実行するコンピュータのファイル システムの /usr/sbin ディレクトリなどにコピーします。wlauth ファイルは weblogic/lib/arch ディレクトリにあり、arch は使用しているプラットフォームの名前です。
wlauth のオーナとパーミッションを変更します。
# chown root wlauth
# chmod +xs wlauth
wlauth の PAM コンフィグレーションを設定します。
Solaris の場合は、/etc/pam.conf ファイルに次の行を追加します。
# Solaris マシンの WebLogic 認証の設定
#
wlauth auth required /usr/lib/security/pam_unix.so.1
wlauth password required /usr/lib/security/pam_unix.so.1
wlauth account required /usr/lib/security/pam_unix.so.1
Linux の場合は、次の行を含むファイルを /etc/pam.d/wlauth という名前で作成します。
#%PAM-1.0
#
# ファイル名 :
# /etc/pam.d/wlauth
#
# シャドウ パスワードを使用しない場合は「shadow」を削除する
auth required /lib/security/pam_pwdb.so shadow
account required /lib/security/pam_pwdb.so
注意: シャドウ パスワードを使用しない場合は、shadow を省略します。
UNIX セキュリティ レルムを使用するには、次の操作を行います。
次の表では、[新しい UnixRealm の作成] ウィンドウで設定する属性について説明します。
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューから UNIX セキュリティ レルムを選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム（この場合は UNIX セキュリティ レルム）の関連付けを定義します。
wlauth が WebLogic Server のクラスパスに入っていない場合、または wlauth 以外のプログラム名を指定した場合は、WebLogic Server を起動したときに Java コマンドライン プロパティを追加しなければなりません。使用するスクリプトを編集し、WebLogic Server を起動して、java コマンドの後に次のオプションを追加します。
-Dweblogic.security.unixrealm.authProgram=wlauth_prog
wlauth_prog を wlauth プログラムの名前と置き換えます。プログラムが検索パスにない場合は、絶対パスも指定します。WebLogic Server を起動します。wlauth プログラムが WebLogic Server パスにあり、wlauth という名前の場合は、この手順は不要です。
RDBMS セキュリティ レルムは BEA 独自のカスタム セキュリティ レルムで、ユーザ、グループ、および ACL をリレーショナル データベースに保存します。RDBMS セキュリティ レルムはサンプルであり、プロダクション環境で使用するためのものではありません。Administration Console を使用して、RDBMS セキュリティ レルムの次の管理機能を実行できます。
|
管理機能 |
Administration Console のサポート |
|---|---|
|
ユーザの作成 |
あり。しかしメモリ中のみ。 |
|
ユーザの削除 |
あり |
|
パスワードの変更 |
なし |
|
グループの作成 |
なし |
|
グループの削除 |
あり |
|
グループ メンバーの追加 |
あり |
|
グループ メンバーの削除 |
あり |
|
ACL の削除 |
なし |
|
ACL の削除 |
なし |
|
パーミッションの追加 |
なし |
|
パーミッションの削除 |
なし |
データベースに入力する SQL スクリプトを使用すると、RDBMS セキュリティ レルムのグループを作成できます。
RDBMS セキュリティ レルムを基にして、プロダクション セキュリティ レルムを作成できます。RDBMS セキュリティ レルムを拡張するには、weblogic.security.acl パッケージの次のインタフェースを使用して RDBMS セキュリティ レルムに管理機能を追加します。
ManageableRealm − グループの作成、ACL の作成と削除、ユーザ、グループ、および ACL のルックアップの実行
User − パスワードの変更
ACL − ユーザおよびグループのパーミッションの追加と削除
これらのインタフェースを使用して RDBMS セキュリティ レルムを拡張した場合、データベース スキーマの更新も必要になることがあります。
注意: サンプルの RDBMS は、自動コミットが有効になっているデータベースでは機能しません。サンプルの RDBMS をベースにして RDBMS を実装する場合、コードでは明示的にコミット文を使用し、データベースでは自動コミット機能を無効にしてください。
RDBMS セキュリティ レルムを使用するには、次の操作を行います。
次の表では、[一般] タブで設定する属性について説明します。
|
属性 |
説明 |
|---|---|
|
[名前] |
AccountingRealm などの RDBMS セキュリティ レルムの名前。 |
|
[レルム クラス] |
RDBMS セキュリティ レルムを実装する WebLogic クラスの名前。Java クラスは WebLogic Server の CLASSPATH に入っていなければならない。 |
次の表では、[データベース] タブで設定する属性について説明します。
コード リスト 14-5 は、WebLogic Server に付属の RDBMS コード サンプル（\samples\examples\security\rdbmsrealm ディレクトリ）の Schema プロパティで入力されたデータベース文を示しています。
コード リスト 14-5 RDBMS セキュリティ レルムのサンプル スキーマ
"getGroupNewStatement=true;getUser=SELECT U_NAME, U_PASSWORD FROM users WHERE U_NAME = ?;
getGroupMembers=SELECT GM_GROUP, GM_MEMBER from groupmembers WHERE GM_GROUP = ?;
getAclEntries=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM aclentries WHERE A_NAME = ? ORDER BY A_PRINCIPAL;
getUsers=SELECT U_NAME, U_PASSWORD FROM users;
getGroups=SELECT GM_GROUP, GM_MEMBER FROM groupmembers;
getAcls=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM aclentries ORDER BY A_NAME, A_PRINCIPAL;
getPermissions=SELECT DISTINCT A_PERMISSION FROM aclentries;
getPermission=SELECT DISTINCT A_PERMISSION FROM aclentries WHERE A_PERMISSION = ?;
newUser=INSERT INTO users VALUES ( ? , ? );
addGroupMember=INSERT INTO groupmembers VALUES ( ? , ? );
removeGroupMember=DELETE FROM groupmembers WHERE GM_GROUP = ? AND GM_MEMBER = ?;
deleteUser1=DELETE FROM users WHERE U_NAME = ?;
deleteUser2=DELETE FROM groupmembers WHERE GM_MEMBER = ?;
deleteUser3=DELETE FROM aclentries WHERE A_PRINCIPAL = ?;
deleteGroup1=DELETE FROM groupmembers WHERE GM_GROUP = ?;
deleteGroup2=DELETE FROM aclentries WHERE A_PRINCIPAL = ?"
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューから RDBMS セキュリティ レルムを選択します。[基本レルム] 属性では、キャッシング レルムと代替セキュリティ レルム（この場合は RDBMS セキュリティ レルム）の関連付けを定義します。
ネットワーク上のディレクトリ サーバなどの既存のユーザ ストアからデータを抽出するカスタム セキュリティ レルムを作成できます。カスタム セキュリティ レルムを使用するには、weblogic.security.acl.AbstractListableRealm インタフェースまたは weblogic.security.acl.AbstractManageableRealm インタフェースの実装を作成し、Administration Console を使用してその実装をインストールします。
カスタム セキュリティ レルムをインストールするには、次の操作を行います。
次の表では、[新しい CustomRealm の作成] ウィンドウの [コンフィグレーション] タブで設定する属性について説明します。
キャッシング レルムをコンフィグレーションするときには、[一般] タブの [基本レルム] 属性のプルダウン メニューからカスタム セキュリティ レルムを選択します。[基本レルム] 属性では、キャッシング レルムとカスタム セキュリティ レルムの関連付けを定義します。
カスタム セキュリティ レルムの記述の詳細については、「カスタム セキュリティ レルムの記述」を参照してください。
セキュリティ レルムの移行
WebLogic Server は、セキュリティ レルム用の管理アーキテクチャを備えています。MBean で実装される管理アーキテクチャにより、Administration Console を使用してセキュリティ レルムを管理できます。以前のリリースの WebLogic Server でのセキュリティ レルムがある場合、以下の情報を使用して新しいアーキテクチャに移行します。
samples\examples\security\rdbmsrealm ディレクトリにあるコード例を使用します。RDBMS セキュリティ レルムを MBean へ変換したら、
RDBMS セキュリティ レルムのコンフィグレーションの手順に従って、データベースへの接続に使用する JDBC ドライバとセキュリティ レルムで使用するスキーマの情報を定義します。
注意: この節では、ファイル レルムにユーザを追加する方法について説明します。代替セキュリティ レルムを使用している場合、ユーザを定義するには、そのレルムで用意されている管理ツールを使用する必要があります。
ユーザ名およびグループ名はユニークでなければなりません。ユーザ名とグループ名では、マルチバイト文字およびカンマ (,) を除くすべての特殊文字を使用できます。
ユーザとは、WebLogic Server セキュリティ レルムで認証されるエンティティのことです。ユーザは、個人または Java クライアントなどのソフトウェア エンティティでもかまいません。各ユーザには、WebLogic Server セキュリティ レルムでユニークな ID が与えられます。システム管理者は、同じセキュリティ レルム内で同一ユーザが重複しないようにする必要があります。
セキュリティ レルムのユーザの定義では、WebLogic Server セキュリティ レルム内のリソースにアクセスするユーザごとにユニークな名前とパスワードを、Administration Console の [ユーザ] ウィンドウで指定します。
WebLogic Server には、system と guest という 2 つの特別なユーザが定義されています。
system ユーザとは、サーバの起動/停止やリソースのロック/ロック解除など、WebLogic Server のシステムレベルの操作を管理する管理者ユーザです。system ユーザとそのパスワードは、WebLogic Server のインストール手順の中で定義します。セキュリティ措置として、system ユーザのパスワードを変更することをお勧めします。詳細については、
システム パスワードの変更を参照してください。
guest ユーザは、WebLogic Server によって自動的に定義されます。許可が不要な場合、クライアントには、WebLogic Server によって guest ID が割り当てられるので、クライアントは guest ユーザが使用可能なすべてのリソースにアクセスできるようになります。クライアントからは、Web ブラウザから要求された場合にユーザ名にもパスワードにも guest と入力するか、Java クライアントで guest をユーザ名およびパスワードとして提供することで、guest ユーザとしてログインできます。デフォルトでは、guest アカウントが有効になってます。
デプロイメントの安全性を強化するために、WebLogic Server は guest アカウントを無効にして実行することをお勧めします。guest アカウントを無効にするには、[セキュリティ] ウィンドウの [一般] タブで [ゲスト不可] 属性を選択します。guest アカウントを無効にしても、アカウント guest にログインできなくなるだけであり、未認証ユーザが WebLogic Server デプロイメントにアクセスすることはできます。
system ユーザと guest ユーザは、WebLogic Server セキュリティ レルムのその他のユーザとほぼ同じです。
ユーザを定義するには、次の操作を行います。
[ユーザ] ウィンドウが表示されます。
ユーザを削除するには、次の操作を行います。
ユーザのパスワードを変更するには、次の操作を行います。
WebLogic Server の使用時には、ユーザがロックされている場合があります。次の手順を実行すると、ユーザのロックを解除できます。
WebLogic Server のユーザとアクセス制御モデルの詳細については、「WebLogic Security の概要」と「セキュリティの基礎概念」を参照してください。
注意: この節では、ファイル レルムにグループを追加する方法について説明します。代替セキュリティ レルムを使用している場合、グループを定義するには、そのレルムで用意されている管理ツールを使用する必要があります。
ユーザ名およびグループ名はユニークでなければなりません。ユーザ名とグループ名では、マルチバイト文字およびカンマ (,) を除くすべての特殊文字を使用できます。
グループは、通常、企業の同じ部門に所属しているなどの共通点を持つユーザの集合を表します。グループは、多数のユーザを効率的に管理する手段です。ACL でグループにパーミッションが付与された場合、そのグループのすべてのメンバがそのパーミッションを持つことになります。パーミッションは、個々のユーザに対してではなく、グループに対して割り当てることをお勧めします。
デフォルトの WebLogic Server には以下のグループがあります。
everyone グループのメンバーです。
guest ユーザを除くセキュリティ レルムのすべての定義済みユーザは自動的に users グループのメンバーです。
system ユーザは、Administrators グループのメンバーです。このグループには、サーバの起動と停止、および動作している WebLogic Server デプロイメントの管理を行うユーザに適切なパーミッションが割り当てられていなければなりません。このグループへのアクセスは制限する必要があります。
次の手順を実行すると、グループを WebLogic Server セキュリティ レルムに登録できます。
[グループ] ウィンドウが表示されます。
グループを削除するには、[グループ] ウィンドウのリスト ボックスでグループの名前を入力し、[削除] をクリックします。
WebLogic Server のグループとアクセス制御モデルの詳細については、「WebLogic Security の概要」と「セキュリティの基礎概念」を参照してください。
ユーザは、WebLogic Server セキュリティ レルムのリソースにアクセスします。ユーザがリソースにアクセスできるかどうかは、そのリソースのアクセス制御リスト（ACL）によって決まります。ACL には、ユーザがリソースとの対話に用いるパーミッションが定義されています。ACL を定義するには、リソースの ACL を作成し、そのリソースに対するパーミッションを指定してから、そのパーミッションを付与するユーザおよびグループを指定します。ACL は、グループに対して割り当てることをお勧めします。
各 WebLogic Server リソースには、1 つまたは複数のパーミッションを付与できます。次の表は、ACL を使用してパーミッションを制限するさまざまな WebLogic Server リソースの機能の一覧を示しています。
注意: JDBC 接続プール用の ACL を指定する際、 filerealm.properties ファイルには system および guest ユーザ用の JDBC 接続プールへのアクセスを特に定義する必要があります。たとえば、次のようになります。
acl.reserve.poolforsecurity=system, guest
acl.reset.ppolforsecurity=system, guest
WebLogic Server リソースの ACL を作成するには、Administration Console を起動して次の手順に従います。
[アクセス コントロール リスト] ウィンドウが表示されます。
たとえば、demopool という名前で、JDBC 接続プール用の ACL を作成します。
リソースに対して設定可能なパーミッションごとに別々の ACL を作成することも、リソースに対するすべてのパーミッションを付与する 1 つの ACL を作成することもできます。たとえば、JDBC 接続プール、demopool に対して、reserve パーミッション用、 reset パーミッション用、shrink パーミッション用にそれぞれ 1 つの ACL を作成できます。または、reserve および reset パーミッション用に 1 つの ACL を作成することもできます。
WebLogic Server でリソースの ACL を作成する場合は、
表 14-16 の構文に従ってリソースを参照しなければなりません。たとえば、demopool という JDBC 接続プールを、weblogic.jdbc.connectionPool.demopool と指定します。
既存の ACL を変更した場合は、[セキュリティ] ノードの [一般] タブで [更新] ボタンをクリックして、WebLogic Server が使用する filerealm.properties ファイルの情報を更新します。
WebLogic Server を起動できるようにするには、サーバを起動するためのパーミッションを特定のグループに付与する必要があります。このセキュリティ対策によって、許可のないユーザが WebLogic Server を起動できなくなります。
デフォルトでは、system ユーザだけが MBean を修正できます。MBean にアクセスして修正できるユーザの数は制限するようにしてください。すべての WebLogic Server MBean にアクセスするには、次のような ACL を使用します。
access.weblogic.admin.mbean=Group or User name
ユーザが MBean へアクセスしようとして失敗した場合、weblogic.management.NoAccessRuntimeException が返されます。サーバ ログには、アクセスしようとしたユーザと MBean を示す詳細が記録されます。
Administration Console を使用してユーザまたはグループにパーミッションを付与する前に、Administrators グループに次のパーミッションを付与する必要があります。
acl.modify.weblogic.admin=Administrators
以下の節では、デジタル証明書を取得する方法、および SSL プロトコルをコンフィグレーションする方法について説明します。
SSL プロトコルの詳細については、「WebLogic Security の概要」と「セキュリティの基礎概念」を参照してください。
プライベート キーとデジタル証明書は、SSL プロトコルを使用する WebLogic Server のデプロイメントごとに必要です。認証局（CA）からデジタル証明書を取得するには、証明書署名リクエスト（CSR）と呼ばれる特定のフォーマットでリクエストを提出する必要があります。WebLogic Server には、CSR を作成する Certificate Request Generator サーブレットが入っています。Certificate Request Generator サーブレットはユーザから情報を収集して、プライベート キー ファイルと証明書リクエスト ファイルを生成します。次に、VeriSign や Entrust.net などの認証局に CSR を提出します。Certificate Request Generator サーブレットを使用する前に、WebLogic Server をインストールして実行しておく必要があります。
注意: Certificate Request Generator サーブレット以外のソースからプライベート キーを入手した場合は、そのキーのフォーマットが PKCS#5/PKCS#8 PEM であることを確認します。
CSR を生成するには、次の手順に従います。
.war ファイルは、\wlserver6.1\config\applications ディレクトリにあります。.war ファイルは、WebLogic Server を起動すると自動的にインストールされます。
https://hostname:port/certificate/
URL の各要素は次のように定義します。
hostname は、WebLogic Server を実行しているマシンの DNS 名です。
port は、WebLogic Server が SSL 接続をリスンするポートの番号です。デフォルトでは 7002 です。
たとえば、WebLogic Server が ogre というマシン上で動作しており、Certificate Request Generator サーブレットを実行するために SSL 通信をデフォルト ポートの 7002 でリスンするようコンフィグレーションされている場合は、Web ブラウザに次の URL を入力しなければなりません。
https://ogre:7002/certificate/
必須属性が空白の場合、または属性に無効な値が指定されている場合は、Certificate Request Generator サーブレットによってメッセージが表示されます。メッセージが表示された場合は、ブラウザの [戻る] ボタンをクリックして、エラーを修正します。
すべての属性が受け付けられると、Certificate Request Generator サーブレットは次のファイルを WebLogic Server のスタートアップ ディレクトリに作成します。
www__com-key.der - プライベート キー ファイル。Administration Console の [SSL] タブの [サーバ キー ファイル名] 属性フィールドに入る名前です。
www__com-request.dem - バイナリ フォーマットの証明書リクエスト ファイル。
www__com-request.pem - 認証局に提出する CSR ファイル。このファイルの内容は .dem ファイルと同じデータですが、E メールにコピーしたり、Web フォームに貼り付けたりできるように、ASCII でエンコードされています。
BEA WebLogic Server を選択します。
wlserver6.1\config\ ディレクトリに保存する必要があります。
SSL プロトコルのコンフィグレーションの詳細については、「 SSL プロトコル用の属性の定義」を参照してください。
-Dweblogic.management.pkpassword=password
password はプライベート キーのパスワード。
プライベート キーとデジタル証明書を取得したら、Certificate Request Generator サーブレットによって生成されたプライベート キーと認証局から入手したデジタル証明書を、\wlserver6.1\config\ ディレクトリにコピーします。
プライベート キーとデジタル証明書は、PEM または Definite Encoding Rules（DER）フォーマットで生成されます。デジタル証明書ファイルのフォーマットは、ファイル名拡張子で識別します。
PEM（.pem） フォーマットのプライベート キー ファイルは、先頭と末尾がそれぞれ次のような行になっています。
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
PEM（.pem） フォーマットのデジタル証明書は、先頭と末尾がそれぞれ次のような行になっています。
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
注意: 使用するデジタル証明書は、ファイル内で BEGIN CERTIFICATE および END CERTIFICATE 行によってそれぞれが区切られた複数のデジタル証明書のうちのいずれかでもかまいません。通常、WebLogic Server 用のデジタル証明書は 1 つのファイル（拡張子は .pem または .der）に入っており、WebLogic Server 認証チェーン ファイルは別のファイルに入っています。2 つのファイルを使用する理由は、異なる WebLogic Server が同じ認証チェーンを共有する場合があるからです。
認証局ファイル内の最初のデジタル証明書は、WebLogic Server 認証チェーンの最初のデジタル証明書となります。ファイル内の次の証明書は、認証チェーン内の次のデジタル証明書になります。ファイル内の最後の証明書は、認証チェーン内の最後となる自己署名デジタル証明書です。
DER（.der）フォーマットのファイルにはバイナリ データが格納されます。WebLogic Server では、ファイル拡張子が認証ファイルの内容と一致する必要があるので、認証局から取得したファイルは正しい拡張子を付けて保存します。
プライベート キー ファイルとデジタル証明書には WebLogic Server の system ユーザだけが読み込み特権を持ち、その他のユーザがアクセスできないように、プライベート キーとデジタル証明書を保護します。複数の認証局のデジタル証明書を持つファイルまたは認証チェーンを格納するファイルを作成する場合は、PEM フォーマットを使用しなければなりません。WebLogic Server には、DER フォーマットと PEM フォーマットを互いに変換するツールが用意されています。詳細については、「WebLogic Server Java ユーティリティの使い方」を参照してください。
SSL 接続が確立されると、WebLogic Server は、信頼された認証局リストと照らし合わせて認証局の ID をチェックして、使用中の認証局が信頼されていることを確認します。
認証局のルート証明書を WebLogic Server の \wlserver6.1\config\ ディレクトリにコピーし、「
SSL プロトコル用の属性の定義」で説明されている属性を設定します。
認証チェーンを利用する場合は、別の PEM エンコード済みデジタル証明書を、WebLogic Server 用のデジタル証明書を発行した認証局のデジタル証明書に追加します。ファイル内の最後のデジタル証明書は、自己署名デジタル証明書（つまり、rootCA 証明書）でなければなりません。
相互認証を利用する場合は、受け付ける認証局のルート証明書を取得して、信頼された CA ファイルにそれを含めます。
セキュア ソケット レイヤ（Secure Sockets Layer: SSL）では、ネットワーク接続している 2 つのアプリケーションが互いの ID を認証できるようにするとともに、アプリケーション間でやりとりされるデータを暗号化することで、セキュアな接続を実現します。SSL プロトコルは、サーバ認証と、必要に応じてクライアント認証、機密性、およびデータ整合性を提供します。
SSL プロトコル用の属性を定義するには、次の手順に従います。
注意: PKCS-8 で保護されたプライベート キーを使用している場合は、WebLogic Server を起動するときに、プライベート キーのパスワードをコマンド ラインで指定する必要があります。
次の表では、[サーバ] ウィンドウの [コンフィグレーション] タブにある [SSL] タブの各属性について説明します。
|
属性 |
説明 |
|---|---|
|
[有効化] |
SSL プロトコルを有効化する。この属性はデフォルトで有効。 |
|
[リスン ポート] |
WebLogic Server が SSL 接続をリスンする専用ポートの番号。デフォルトは 7002。 |
|
[サーバ キー ファイル名] |
WebLogic Server 用のプライベート キーのパスと名前。 パスは WebLogic Server のインストールされたルート ディレクトリを起点とする。次に例を示す。 \ ファイル拡張子（ |
|
[サーバ認証ファイル名] |
WebLogic Server の ID を確立するデジタル証明書ファイルの絶対パスと名前。 パスは WebLogic Server のインストールされたルート ディレクトリを起点とする。次に例を示す。 \ ファイル拡張子（ |
|
[サーバ認証チェーン ファイル] |
WebLogic Server のデジタル証明書に署名するために使用するデジタル証明書の絶対パス。 パスは WebLogic Server のインストールされたルート ディレクトリを起点とする。次に例を示す。 \ ファイル拡張子（ WebLogic Server で証明書チェーンを使用する場合、そのファイルには WebLogic Server のデジタル証明書に署名するために使用されるデジタル証明書が最初のメンバーとして格納され、2 番目のメンバーには最初のデジタル証明書に署名するために使用されるデジタル証明書が格納されていなければならない。ファイル内の最後のデジタル証明書は自己署名でなければならない。 [サーバ認証チェーン ファイル] 属性では、少なくとも 1 つのデジタル証明書が必要。ファイルに 1 つのデジタル証明書しかない場合、そのデジタル証明書は自己署名でなければならない（つまり、ルート CA デジタル証明書でなければならない）。 認証局からデジタル証明書を取得する場合、認証局およびその他の上位のデジタル証明書を認証局から受け取る。 |
|
[クライアント認証を強制する] |
クライアントが信頼できる認証局からのデジタル証明書を WebLogic Server に提示しなければならないかどうかを定義する。 |
|
[信頼性のある CA ファイル名] |
WebLogic Server によって信頼された認証局のデジタル証明書を格納するファイルの名前。この属性で指定したファイルには、認証局の 1 つまたは複数のデジタル証明書が格納される。ファイル拡張子（ |
|
[認可済み認証機関] |
CertAuthenticator インタフェースを実装する Java クラスの名前。 |
|
[暗号化キーを使用] |
WebLogic Server のプライベート キーがパスワードで暗号化されることを指定する。デフォルトでは無効。 この属性を指定した場合は、保護されたキーを使用する必要がある。また、WebLogic Server を起動するときには、次のコマンドライン オプションを使用して WebLogic Server を起動する。
|
|
[Java を使用] |
この属性を選択すると、ネイティブ Java ライブラリを使用できるようになる。WebLogic Server は、SSL プロトコルの pure-Java 実装を提供する。ネイティブ Java ライブラリを使用すると、Solaris、Windows NT、および IBM AIX プラットフォーム上で SSL 処理のパフォーマンスが向上する。デフォルトでは、この属性は無効。 |
|
[ハンドラを有効化] |
WebLogic Server が、次のいずれかの理由でクライアント認証に失敗した SSL 接続を拒否するかどうかを指定する。
SSL ハンドラのデフォルト設定では、WebLogic Server インスタンスから別の WebLogic Server インスタンスへの SSL 接続は 1 つしか許可されない。たとえば、WebLogic Server の EJB は別の Web サーバで HTTPS ストリームを開く場合がある。[ハンドラを有効化] 属性が有効な場合、WebLogic Server は SSL 接続のクライアントとして動作する。デフォルトでは、この属性は有効。 この属性は、SSL 接続を開始するために独自の実装を提供する場合にのみ無効にする。 注意: SSL ハンドラは、WebLogic Server が SSL 接続の受け付けを管理する機能には影響しない。 |
|
[キーの有効期間をエクスポート] |
WebLogic Server がドメスティック サーバとエクスポータブル クライアントとの間で、新規のキーを生成する前に、エクスポータブル キーを使用する回数。新規のキーの生成前にキーを使用する回数が少ないほど、WebLogic Server のセキュリティが高くなる。デフォルトの使用回数は 500 回。 |
|
[ログイン タイムアウト ミリ秒] |
WebLogic Server が SSL 接続のタイムアウトまで待機するミリ秒数。SSL 接続は、通常の接続よりも時間がかかる。クライアントがインターネット経由で接続する場合は、ネットワーク レイテンシに対応するためにデフォルト値を大きくする。デフォルト値は 25,000 ミリ秒。 |
|
[認可キャッシュ サイズ] |
WebLogic Server がトークン化して保存するデジタル証明書の数。デフォルトは 3。 |
|
[ホスト名検証を無視] |
デフォルトのホスト名検証を無効にする。WebLogic Server のホスト名検証では、デジタル証明書の Subject DN と SSL 接続を開始したサーバのホスト名を比較する。ホスト名検証を実行しない場合（たとえば、WebLogic Server 付属のデモ用デジタル証明書を使用する場合）、この属性をチェックする。この属性を無効にすると、WebLogic Server は介在者の攻撃に対して無防備になる。 プロダクション環境でデモ用デジタル証明書を使用したり、ホスト名検証を無効にしたりすることは望ましくない。 |
|
[ホスト名の検証] |
ホスト名検証インタフェースを実装する Java クラスの名前。 |
注意: 以前のリリースの WebLogic Server では、自己署名されているが、[サーバ認証ファイル名] 属性（または weblogic.security.certificate.server プロパティ）で許可されてないデジタル証明書を定義することができました。ただし、これは優れたセキュリティ ポリシーではありませんでした。現在は、[サーバ認証ファイル名] 属性と [サーバ認証チェーン ファイル] 属性の両方を定義する必要があります。
PKCS#7 ファイルの使い方
WebLogic Server では、PKCS#7 ファイルを使用することができます。ただし、ファイルに記述されている証明書チェーンを p7b フォーマットの個々のファイルに分け、それらの p7b ファイルを PEM フォーマットに変換してから付加して、単一の PEM ファイルにする必要があります。PKCS#7 ファイルはそれぞれ、以下の部分から成ります。
サーバのデジタル証明書と信頼性のある CA 証明書は、別々の p7b ファイルに分ける必要があります。
この節で示す手順を実行する前に、ファイルをテキスト エディタで開いて以下の情報を探すことで、ファイルが PKCS#7 フォーマットであることを確かめてください。
"Base 64 encoded certificate with CA certificate chain in pkcs7 format"
PKCS#7 ファイルを WebLogic Server で使用するには、以下の手順に従います。
servername.p7b と CA.p7b) にコピーします。
p7b ファイルの一方をダブル クリックします。
[証明書] ウィンドウが表示されます。
p7b ファイルを選択します。
生成されるファイルは、PEM フォーマットになっています。
p7b ファイルに対して、ステップ 3 〜 11 を実行します。
なお、デジタル証明書の間に空白行を入れることはできません。
SSL セッション キャッシングのパラメータの変更
WebLogic Server 6.1 サービス パック 2 では、SSL コードに SSL セッション キャッシングのパラメータが含まれています。キャッシュされた SSL セッションを使用すると、接続では再度 SSL ハンドシェークを行う必要がなくなります。接続は、中断されたところからそのまま再開されます。キャッシュされた SSL セッションを使用することで、アプリケーションでは SSL セッションの確立に要する時間を大幅に短縮できるので、パフォーマンスが大幅に向上します。キャッシュされた SSL セッションを使用するには、クライアントとサーバが SSL セッションをキャッシュする機能を持っている必要があります。ブラウザはすべて、SSL セッションをキャッシュする機能を持っています。
サーバセッション キャッシュは、TTL キャッシュに保存されます。TTL キャッシュの詳細については、「 キャッシング レルムのコンフィグレーション」を参照してください。クライアントサイドの SSL セッション キャッシュでは、実行スレッドの SSL セッションを 1 つだけ保持します。
SSL セッション キャッシングはデフォルトで有効です。次のコマンド ライン フラグを使用すると、サーバセッション キャッシュのデフォルト サイズおよび存続期間を変更できます。
-Dweblogic.security.SSL.sessionCache.size=211
-Dweblogic.security.SSL.sessionCache.ttl=600
|
パラメータ |
最小 |
最大 |
デフォルト |
|---|---|---|---|
|
|
1 |
65537 |
211 |
|
|
1 |
max Integer.MAX_VALUE |
600 |
WebLogic Server が相互認証向けにコンフィグレーションされている場合、クライアントは、信頼された認証局のリストと照らし合わせてデジタル証明書を検証する WebLogic Server に、デジタル証明書を提示する必要があります。
SSL プロトコルと証明書向けに WebLogic Server をコンフィグレーションするには、「 SSL プロトコルのコンフィグレーション」の手順に従います。
WebLogic Server が使用する認証局のルート証明書を \wlserver6.1\config ディレクトリにコピーします。クライアントは、相互認証の際に、信頼された認証局のいずれかが発行したデジタル証明書を提示する必要があります。
相互認証をコンフィグレーションするには、Administration Console の [サーバ] ウィンドウの [コンフィグレーション] タブにある [SSL] タブで [クライアント認証を強制する] オプションをチェックします。デフォルトでは、このフィールドは無効です。
SSL を使用した RMI over IIOP のコンフィグレーション
SSL プロトコルを使用すると、RMI リモート オブジェクトへの IIOP 接続を保護できます。SSL プロトコルは、認証を通じて接続を保護し、オブジェクト間のデータ交換を暗号化します。SSL プロトコルを使用して RMI over IIOP 接続を保護するには、次の手順に従います。
host2ior ユーティリティを使用して、WebLogic Server IOR をコンソールに出力します。host2ior ユーティリティでは、SSL 接続用と非 SSL 用に 2 種類のインターオペラブル オブジェクト参照（IOR）が出力されます。IOR のヘッダは、IOR が SSL 接続で使用できるかどうかを示します。
RMI over IIOP の使い方の詳細については、『WebLogic RMI over IIOP プログラマーズ ガイド』を参照してください。
WebLogic Server のリソースにアクセスするためのパスワードを保護することは重要です。ユーザ名とパスワードは以前、WebLogic Server セキュリティ レルムにクリア テキストで保存されていました。現在、WebLogic Server では、すべてのパスワードがハッシュ化されています。クライアントのリクエストを受け取ると、WebLogic Server はクライアントが提示するパスワードをハッシュ化して、ハッシュ化済みパスワードと一致するかどうか比較します。
各 filerealm.properties ファイルは、パスワードをハッシュ化するために使用する SerializedSystemIni.dat ファイルに関連付けられます。SerializedSystemIni.dat ファイルは、インストール時に \wlserver6.1\config\ ディレクトリに置かれます。
何らかの理由で SerializedSystemIni.dat ファイルが破損した場合は、WebLogic Server を再コンフィグレーションしなければなりません。
以下の注意事項を考慮してください。
SerializedSystemIni.dat ファイルのバックアップを作成し、関連する filerealm.properties ファイルのコピーと同じ場所に入れます。
SerializedSystemIni.dat ファイルにパーミッションを設定します。
weblogic.properties ファイルがある場合は、Administration Console のメイン ウィンドウで Convert weblogic.properties オプションを使用して、weblogic.properties ファイルを config.xml ファイルに変換します。ファイルが変換されると、既存のすべてのパスワードが保護されます。
config.xml ファイルには、クリア テキスト形式のパスワードが存在しなくなりました。クリア テキスト形式のパスワードに代わって、config.xml ファイルには暗号化およびハッシュ化されたパスワードが格納されます。暗号化パスワードは、別のドメインにコピーできません。その代わりに、config.xml ファイルを編集し、既存の暗号化およびハッシュ化されたパスワードをクリア テキストのパスワードで置換して、そのファイルを新しいドメインにコピーすることはできます。Administration Console は、次にそのファイルに書き込むときにパスワードを暗号化およびハッシュ化します。
セキュリティ攻撃では、パスワードを推測する方法が一般的です。ハッカーは、こうした攻撃でユーザ名とパスワードをさまざまに組み合わせてコンピュータにログ インしようとします。WebLogic Server では、パスワードを保護するための一連の属性を設けることで、パスワードの推測に対する保護を強化しています。
WebLogic Server デプロイメントでパスワードを保護するには、次の手順に従います。
次の表では、[パスワード] タブの各属性について説明します。
WebLogic Server では、監査プロバイダを作成して、認証リクエストの受け取り、許可の成否、無効なデジタル証明書の提出などのセキュリティ イベントの通知を受け取ったり処理したりすることができます。
監査プロバイダを使用するには、weblogic.security.audit.AuditProvider インタフェースの実装を作成します。作成したら、Administration Console を使用してその実装をインストールし、アクティブにします。
監査プロバイダをインストールするには、Administration Console の [セキュリティ] ノードの [一般] タブの [監査プロバイダ クラス] 属性で、AuditProvider クラスの実装に名前を付けます。WebLogic Server を再起動します。
監査プロバイダの記述の詳細については、「セキュリティ イベントの監査」を参照してください。接続フィルタの作成例については、インストールされている WebLogic Server の \samples\examples\security ディレクトリに入っている LogAuditProvider のサンプルを参照してください。
クライアントの出所やプロトコルに基づいてクライアントの接続を受け付けるか拒否するかを選択する接続フィルタを作成できます。クライアントが接続を完了し、何らかの処理を実行する前に、WebLogic Server は、クライアントの IP 番号とポート、プロトコル（HTTP、HTTPS、T3、T3S、または IIOP）、および WebLogic Server のポート番号を接続フィルタに渡します。この情報を調べることで、接続を許可するか、FilterException を生成して接続を終了するかを選択できます。
接続フィルタを使用するには、まず、weblogic.security.net.ConnectionFilter インタフェースの実装を作成する必要があります。作成したら、Administration Console を使用してその実装をインストールします。
接続フィルタをインストールするには、Administration Console の [セキュリティ] ウィンドウの [詳細設定] タブの [接続フィルタ] 属性で、weblogic.security.net.ConnectionFilter インタフェースの実装に名前を付けます。WebLogic Server を再起動します。
接続フィルタの記述の詳細については、「ネットワーク接続のフィルタリング」を参照してください。接続フィルタの作成例については、インストールされている WebLogic Server の \samples\examples\security ディレクトリに入っている SimpleConnectionFilter のサンプルを参照してください。
Java 2（JDK 1.2 または 1.3）環境で WebLogic Server を実行する場合、WebLogic Server では Java 2 の Java セキュリティ マネージャを使用して WebLogic Server リソースに追加のアクセス制御を提供できます。Java 仮想マシン（JVM）には、セキュリティ ポリシー ファイルから管理できるセキュリティ メカニズムが組み込まれています。Java セキュリティ マネージャを使用すると、CodeSource または SignedBy クラスに一連のパーミッションを強制的に付与できます。パーミッションによって、JVM のインスタンスで動作する特定のクラスが、特定の実行時の処理を行うかどうかを制御できます。多くの場合、脅威モデルでは、悪意あるコードが JVM で実行されることを想定していないため、Java セキュリティ マネージャは必要ありません。アプリケーション サービス プロバイダが WebLogic Server を使用し、未知のクラスが実行されるような場合では、Java セキュリティ マネージャが必要です。
注意: WebLogic Server の 6.0 より前のリリースでは、Java セキュリティ マネージャは、WebLogic Server の起動時に -Dweblogic.security.manager プロパティを使用することで有効になりました。WebLogic Server バージョン 6.0 以降ではプロパティが変更されていることに注意してください。
WebLogic Server で Java セキュリティ マネージャを使用するには、WebLogic Server の起動時に -Djava.security.manager property プロパティを指定します。
Java セキュリティ マネージャでは、パーミッションを定義するセキュリティ ポリシー ファイルを使用します。セキュリティ ポリシーの絶対パス名は、WebLogic Server の起動時に -Djava.security.policy プロパティで指定します。セキュリティ ポリシー ファイルを指定しないで Java セキュリティ マネージャを有効にする場合、Java セキュリティ マネージャでは、$JAVA_HOME\lib\security ディレクトリの java.security および java.policy ファイルで定義されるデフォルトのセキュリティ ポリシーを使用します。
WebLogic Server には weblogic.policy というサンプルのセキュリティ ポリシー ファイルがあります。このファイルにはデフォルトのパーミッションが含まれています。
WebLogic Server デプロイメントで Java セキュリティ マネージャのセキュリティ ポリシー ファイルを使用するには、次の操作を行います。
weblogic.policy ファイルの次の行を編集して、指定の場所を WebLogic Server のインストール先で置き換えます。
grant codebase "file://BEA/-"{
permission java.io.FilePermission "D:${/}BEA${/}=", ...
注意: この変更は、インストール先ディレクトリの構造が、『BEA WebLogic Server インストール ガイド』で説明されているものと同じ構造であることを前提としています。
weblogic.policy ファイルに次のような grant ブロックとパーミッションを追加します。
grant {
permission java.io.FilePermission
"D:{/}BEA${/}wlserver6.1${/}weblogic${/}management${/}console${
/}-", "read";
permission java.io.FilePermission
"D:{/}BEA${/}wlserver6.1${/}config${/}${/}applications${/}.wl_t
emp_do_not_delete${/}weblogic${/}management${/}console${/}-",
"read";
permission java.util.PropertyPermission "user.*", "read";
};
CLASSPATH に追加のディレクトリがある場合、または追加のディレクトリにアプリケーションをデプロイしている場合は、それらのディレクトリに対する特定のパーミッションを weblogic.policy ファイルに追加します。
weblogic.policy ファイルのバックアップを作成し、安全な場所に保管します。
weblogic.policy ファイルにパーミッションを設定します。
weblogic.policy ファイルを使用するには、WebLogic Server の起動時に次のようなプロパティを使用します。
$java... -Djava.security.manager\
-Djava.security.policy==D:/BEA/wlserver6.1/lib/weblogic.policy
警告: Java セキュリティ マネージャは、管理サーバと管理対象サーバの起動中には一部無効になります。 起動シーケンスでは、現在の Java セキュリティ マネージャは無効になり、checkRead() メソッドを無効にしてあるバージョンの Java セキュリティ マネージャに置き換えられます。 無効になっている間、このメソッドは起動シーケンスのパフォーマンスを大きく改善しながら、セキュリティの低下は最小限に抑えます。WebLogic Server のスタートアップ クラスは、この一部無効になっている Java セキュリティ マネージャで実行され、そのため、クラスは、セキュリティを考慮するため、ファイルを読み込んで、慎重に調べる必要があります。
Java セキュリティ マネージャの詳細については、Java 2 に付属している Javadoc を参照してください。
サードパーティまたはユーザが作成したクラスの weblogic.policy ファイルの変更
サーバサイド ユーザ コードを置く最適の位置は、weblogic/myserver/serverclasses ディレクトリです。そのディレクトリに入っていないサードパーティまたはユーザが作成するクラスがある場合は、以下のステップを実行して、保護します。
weblogic.policy ファイル内の "grant codeBase..." からそれを閉じる括弧およびセミコロンまでのコード ブロック全体をコピーします。
weblogic.policy ファイルのさっきコピーした箇所の下に貼りつけます。
grant codeBase 文と permission.java.io.FilePermission 文について、そのディレクトリがサードパーティまたはユーザが作成したコードの位置を指すように編集します。
この手順で、WebLogic Server のためのパーミッションとそっくり同じパーミッションを持つ独自のコード用のセキュリティ ポリシーを作成します。 これらのパーミッションを詳細に検討し、そのディレクトリに対して求めるセキュリティ ポリシーになってるかどうか確認してください。
警告: UNIX システムでの JavaSoft JDK バージョン 1.2.1では、 WebLogic Server ソフトウェアがファイル システムのルート ディレクトリやディスク ドライブにインストールされている場合、セキュリティ ポリシーが正しく適用されません。ポリシーが正しく適用されるのは、grant codeBase URL 内のパスにあるコンポーネントが 1つだけの場合です。 たとえば、c:\test\weblogic （または Solaris なら /home/weblogic）に WebLogic Server をインストールしている場合、たとえセキュリティ ポリシー ファイルで正しい URL を使用していても、AccessControlException となります。
この制限を回避するためにできることは、 WebLogic をルート ディレクトリにインストールするか（推奨）、またはその URL を変更して、WebLogic をインストールしたパスへの最初のコンポーネントだけを含むようにするかです。たとえば、次のようにします。
grant codeBase "file:/c:/test/" {
指定した URL のなかで「/-」を使用すると、問題が発生します。この問題は、 Sun Microsytems でもバグ #4261298 として認識されていますが、JDK 内でのバグではないと判断されています。 「パスの最期に“/-” が付いていると、その前の要素が 1 つのディレクトリであるということを意味し、 その下の要素すべてに対して機能を許可します。そのディレクトリ自体を読み込めるという意味ではない」とのことです。このニュアンスに対応するには、そのディレクトリだけを含む（「/-」の付かない） FilePermission エントリをもう 1 つ追加することです。
レコーディング セキュリティ マネージャ ユーティリティの使い方
レコーディング セキュリティ マネージャ ユーティリティを使用すると、WebLogic Server の起動時または動作中に発生するパーミッションの問題を検出できます。ユーティリティでは、ユーティリティが見つけたパーミッションの問題を解決するために、セキュリティ ポリシー ファイルに追加できるパーミッションを出力します。レコーディング セキュリティ マネージャは BEA dev2dev Online で入手できます。
セキュリティ コンテキストの伝播を使用すると、WebLogic Server 環境で動作している Java アプリケーションから、BEA Tuxedo ドメイン内のオブジェクトにアクセスして操作することができます。WebLogic Server の BEA WebLogic Enterprise Connectivity コンポーネントには、セキュリティ コンテキストの伝播機能があります。
セキュリティ コンテキストの伝播を使用する場合、WebLogic Server セキュリティ レルムで定義されているユーザのセキュリティ ID が、WLEC 接続プールの一部をなすネットワーク接続を通して BEA Tuxedo ドメインに送信される Internet Inter-ORB Protocol（IIOP）リクエストのサービス コンテキストの一部として伝播されます。WLEC 接続プール内の各ネットワーク接続は、定義済みのユーザ ID を使用して認証されます。
セキュリティ コンテキストの伝播を使用するには、WebLogic Server からアクセスする BEA Tuxedo ドメインごとに WLEC 接続プールを作成します。WebLogic Server は、IIOP 接続を各 WLEC 接続プールに追加します。WebLogic Server 環境の Java アプリケーションは、WLEC 接続プールから取得した IIOP 接続を使用して、BEA Tuxedo ドメインのオブジェクトを呼び出したり、処理を要求したりします。
セキュリティ コンテキストの伝播を使用する前に、TUXDIR\lib\wleorb.jar と TUXDIR\lib\wlepool.jar を、startAdminWebLogic.sh ファイルまたは startAdminWebLogic.cmd ファイルの CLASSPATH 変数に追加します。
詳細については、『WebLogic Enterprise Connectivity ユーザーズ ガイド』を参照してください。
セキュリティ コンテキストの伝播を実装するには、次の操作を行います。
tpusradd コマンドを実行して、WebLogic Server ユーザを WebLogic エンタープライズ ドメインで許可済みのユーザとして定義します。
ISL コマンドの -E オプションを設定して、WebLogic Server レルムから伝播されたセキュリティ コンテキストを認識して利用するよう IIOP リスナ/ハンドラをコンフィグレーションします。ISL コマンドの -E オプションでは、プリンシパル名を指定する必要があります。プリンシパル名によって、WLEC 接続プールが WebLogic エンタープライズ ドメインにログ インするために使用するプリンシパルが定義されます。プリンシパル名は、WLEC 接続プールを作成するときに [ユーザ名] 属性に定義した名前と一致しなければなりません。
WebLogic Server 環境と BEA Tuxedo 環境の間で証明書に基づく認証を使用する場合は、WebLogic Server 環境から BEA Tuxedo CORBA オブジェクトへの接続を確立するときに新しい SSL ハンドシェークが実行されます。同じ SSL ネットワーク接続を使用して複数のクライアント リクエストをサポートするには、そうした処理を行うように証明書を次のように設定しなければなりません。
TUXDIR\udataobj\security\keys ディレクトリに入れます。
UBBCONFIG ファイルでは、tpusradd コマンドを使用して WebLogic Server ユーザを BEA Tuxedo ユーザとして定義します。
-E オプションを使用して UBBCONFIG ファイルの IIOP リスナ/ハンドラを定義して、WebLogic Server ユーザが認証用に使用されることを示します。
SEC_PRINCIPAL_NAME オプションでデジタル証明書を指定し、-S オプションを使用して、セキュア ポートを BEA Tuxedo ドメインと WebLogic Server セキュリティ レルムとの間で使用することを示します。
UBBCONFIG ファイルの詳細については、BEA Tuxedo のマニュアルの「Creating a Configuration File」を参照してください。
corbalocs プレフィックスの詳細については、BEA Tuxedo のマニュアルの「Understanding the Address Formats of the Bootstrap Object」を参照してください。
BEA Tuxedo のセキュリティ レベルの詳細については、BEA Tuxedo のマニュアルの「Defining a Security Level」を参照してください。
SSL 証明書の検証
これまでのリリースでは、証明書チェーンの各証明書が認証局 (CA) によって発行されていることを WebLogic Server は確認していませんでした。この問題は、誰かが信頼性のある CA から個人証明書を取得し、その証明書を使って他の証明書を発行しても、WebLogic Server はその無効な証明書を検出できないことを意味しました。WebLogic Server で使用されているすべての X509 V3 CA 証明書が CA として定義されている Basic Constraint 拡張を持つことで、証明書チェーン内のすべての証明書が認証局によって発行されたものであることを保証しなければならないようにするため、パッチ (CR090101_610sp4) が作成されました。デフォルトでは、この条件を満たさない CA 証明書はすべて拒否されます。ここでは、このパッチのインストール方法、および証明書検証のレベルを制御するコマンドライン引数について説明します。
インストール方法
パッチ CR090101_610sp4 をインストールするには:
%WL_HOME%\common\nodemanager\config\democert.pem
%WL_HOME%\common\nodemanager\config\demokey.pem
%WL_HOME%\samples\server\config\examples\demo.crt
%WL_HOME%\samples\server\config\examples\democert.pem
%WL_HOME%\samples\server\config\examples\demokey.pem
%WL_HOME%\samples\server\examples\trusted.crt
%WL_HOME%\samples\server\config\petstore\demo.crt
%WL_HOME%\samples\server\config\petstore\democert.pem
%WL_HOME%\samples\server\config\petstore\demokey.pem
%WL_HOME%\samples\server\config\petstore\trusted.crt
%WL_HOME%\server\lib\cacerts
%WL_HOME%\server\lib\demo.crt
%WL_HOME%\server\lib\trusted.crt
通常は、これらのファイルは変更されていません。しかし、変更してある場合は、更新された証明書、プライベート キー、およびキーストアのインストールを続ける方法を決める必要があります。たとえば、パッチからサービス パックの JAR ファイルだけを選択してインストールすることもできます。
WL_HOME で解凍し、zip ファイルのディレクトリ構造を維持します。
WebLogic Server のインストール環境に、以下のファイルが追加されます。
%WL_HOME%\server\lib\CR090101_610sp4_webservice.jar
%WL_HOME%\server\lib\CR090101_610sp4_websvssl.jar
%WL_HOME%\server\lib\CR090101_610sp4_websvssl_pj.jar
%WL_HOME%\server\lib\CR090101_610sp4_.jar
WebLogic Server インストール環境の以下のファイルは変更されます。
%WL_HOME%\common\nodemanager\config\democert.pem
%WL_HOME%\common\nodemanager\config\demokey.pem
%WL_HOME%\samples\server\config\examples\demo.crt
%WL_HOME%\samples\server\config\examples\democert.pem
%WL_HOME%\samples\server\config\examples\demokey.pem
%WL_HOME%\samples\server\examples\trusted.crt
%WL_HOME%\samples\server\config\petstore\demo.crt
%WL_HOME%\samples\server\config\petstore\democert.pem
%WL_HOME%\samples\server\config\petstore\demokey.pem
%WL_HOME%\samples\server\config\petstore\trusted.crt
%WL_HOME%\server\lib\cacerts
%WL_HOME%\server\lib\demo.crt
%WL_HOME%\server\lib\trusted.crt
名前の衝突を防ぐため、新しい demo CA の証明書の Subject DN は、既存の demo CA の証明書のものとは異なります。Subject DN が変更されたことで、新旧の証明書チェーンの区別も容易になっています。新しい demo CA および demo1024 CA の証明書では、Subject DN の Common Name に Constraints が含まれています。
エンド エンティティ証明書だけがある場合は、Issuer DN を見ることで古いものか新しいものかを確認することもできます。
%WL_HOME%\server\bin\setWLSEnv.cmd
%WL_HOME%\server\bin\startWLS.cmd
%WL_HOME%\server\bin\startNodeManager.cmd
CLASSPATH の weblogic_sp.jar の前に次のファイルを追加します。
%WL_HOME%\server\lib\CR090101_610sp4_webservice.jar;
%WL_HOME%\server\lib\CR090101_610sp4_.jar;
$WL_HOME/server/bin/setWLSEnv.sh
$WL_HOME/server/bin/startWLS.sh
$WL_HOME/server/bin/startNodeManager.sh
CLASSPATH の weblogic_sp.jar の前に次のファイルを追加します。
$WL_HOME/server/lib/CR090101_610sp4_webservice.jar;
$WL_HOME/lib/CR090101_610sp4.jar;
パッチが適用されていない古いアプリケーションは、このパッチでインストールされた新しい demo CA の証明書を信頼しません。たとえば、古い demo CA 証明書をまだ信頼しているクライアントは、新しい demo 証明書チェーンを使用するサーバを拒否します。この問題を解決するには、このパッチで提供される新しい demo CA を含むよう、クライアントの信頼できる CA のリストを更新してください。
証明書検証のレベルの制御
デフォルトでは、WebLogic Server は、CA として定義されている Basic Constraint 拡張を持たない証明書チェーン中の証明書を、すべて拒否します。ただし、この要件を満たさない証明書を使用したり、IETF RFC 2459 標準に準拠するようセキュリティのレベルを上げたりすることができます。WebLogic Server が実行する証明書検証のレベルを制御するには、次のコマンドライン引数を使用します。
-Dweblogic.security.SSL.enforceConstraints
表 14-23 は、このコマンドライン引数のオプションの説明です。
表14-23 -Dweblogic.security.SSL.enforceConstraints のオプション
証明書チェーンの検査
既存の証明書チェーンが WebLogic Server によって拒否されるかどうかを検査するために、ValidateCertChain コマンドライン ユーティリティが提供されています。このユーティリティは、PEM ファイル、PKCS-12 ファイル、PKCS-12 キーストア、および JDK キーストアの証明書チェーンを使用します。完全な証明書チェーンを使用する必要があります。ValidateCertChain コマンドライン ユーティリティの構文は、以下のとおりです。
java utils.ValidateCertChain -file pemcertificatefilename
java utils.ValidateCertChain -pem pemcertificatefilename
java utils.ValidateCertChain -pkcs12store pkcs12storefilename
java utils.ValidateCertChain -pkcs12file pkcs12filename password
java utils.ValidateCertChain -jks alias storefilename [storePass]
有効な証明書チェーンの例:
java utils.ValidateCertChain -pem zippychain.pem
Cert[0]: CN=zippy,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Cert[1]: CN=CertGenCAB,OU=FOR TESTING
ONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain appears valid
無効な証明書チェーンの例:
java utils.ValidateCertChain -jks mykey mykeystore
Cert[0]: CN=corba1,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
CA cert not marked with critical BasicConstraint indicating it is a CA
Cert[1]: CN=CACERT,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US
Certificate chain is invalid
証明書に関する問題のトラブルシューティング
パッチを適用する前は動作していた SSL 通信が、パッチのインストール後は失敗するようになった場合は、おそらく、WebLogic Server が使用する証明書チェーンが検証で不合格になっているのが問題です。
証明書チェーンが拒否されている箇所を特定し、受け付けられる証明書チェーンに更新するのか、または -Dweblogic.security.SSL.enforceConstraints コマンドライン引数の設定を変更するのかを決定してください。
証明書に関する問題のトラブルシューティングでは、次のいずれかの方法を使用します。
ValidateCertChain コマンドライン ユーティリティを使って、証明書チェーンが受け付けられるかどうかを検査します。
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次のメッセージは、SSL の障害が証明書チェーンの問題によるものであることを示しています。
<CA certificate rejected. The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical>
一方向の SSL を使用している場合は、クライアントのログでこのエラーを探します。相互 SSL を使用している場合は、クライアント ログとサーバ ログでこのエラーを探します。
|
|
|