セキュリティ管理の概念

WebLogic Serverのセキュリティ・レルム

WebLogic Serverのセキュリティ・サービスは、セキュリティの構成と管理を簡素化しながらも、WebLogic Serverデプロイメントを保護する堅牢な機能を提供します。セキュリティ・レルムは、スコーピング(有効範囲の設定)メカニズムとして機能します。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。1つのドメインに複数のセキュリティ・レルムを構成およびアクティブ化できますが、デフォルトの管理レルムに指定できるのはそのうちの1つだけです。

WebLogic Serverには、デフォルトのセキュリティ・レルムmyrealmがあり、WebLogicの裁決、認証、IDアサーション、認可、ロール・マッピング、および資格証明マッピングの各プロバイダがデフォルトで構成されています。

新しいセキュリティ・レルムを構成して認証機能と認可機能をカスタマイズし、必要なセキュリティ・サービスを用意します。次に、その新しいセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定します。

WebLogic Serverのデフォルト・セキュリティ構成については、「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。

セキュリティ・レルムを構成してデフォルト・セキュリティ・レルムに設定する方法については、デフォルト・セキュリティ構成のカスタマイズを参照してください。

セキュリティ・プロバイダ

セキュリティ・プロバイダは、認証や認可など、セキュリティの特定の側面を処理するモジュール・コンポーネントです。アプリケーションではデフォルトのWebLogicセキュリティ・プロバイダでサービスを利用できますが、WebLogicセキュリティ・サービスのインフラストラクチャは柔軟性が高いので、セキュリティ・ベンダーで独自のカスタム・セキュリティ・プロバイダをWebLogic Server用に作成することもできます。 WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダを適宜組み合せて独自のセキュリティ・ソリューションを構築することができるので、ある分野では新たな技術の進歩を利用しつつ、それ以外の分野では実証済みの手法を堅持できるようになります。WebLogicリモート・コンソールを使用すると、統合された単一の管理インタフェースを通じてすべてのセキュリティ・プロバイダを管理できます。

WebLogicセキュリティ・サービスは、以下のセキュリティ・プロバイダをサポートしています。

認証 - ユーザーまたはシステム・プロセスの身元を証明または確認するプロセスのことです。認証にはまた、必要に応じて、身元情報を記憶したり、トランスポートしたり、様々なシステム・コンポーネントの利用に供する働きもあります。WebLogicセキュリティ・サービスによってサポートされる認証プロバイダは、以下の種類の認証を提供します。
- ユーザー名とパスワードによる認証
- WebLogic Serverで直接行われる証明書ベースの認証
- 外部Webサーバーを介してプロキシされるHTTP証明書ベースの認証
IDアサーション - 境界認証(トークンを使用する特殊なタイプの認証)を行う認証プロバイダを、IDアサーション・プロバイダと呼びます。IDアサーションでは、リクエストの外部に存在するクライアント提供のトークンを使用してクライアントのIDを確立します。したがって、IDアサーション・プロバイダの機能は、トークンを検証してユーザー名にマップすることです。このマッピングがいったん完了すれば、認証プロバイダのLoginModuleを使用してユーザー名がプリンシパル(認証済みのユーザー、グループ、またはシステム・プロセス)に変換されます。
認可 - ユーザーとWebLogicリソースとのやり取りを限定して、整合性、機密性、および可用性を確保するプロセスです。つまり、認証プロバイダによってユーザーのIDが確立したら、認可はそのユーザーによるWebLogicリソースへのアクセスを許可するかどうかを決定します。認可プロバイダは、これらのサービスを提供します。
ロール・マッピング - 1つまたは複数のロールを複数のユーザーに割り当て、特定のロールを持つユーザーのアクセス権を指定できます。ロール・マッピング・プロバイダは、指定されたリソースについてリクエスト側に付与される一連のロールを取得します。ロール・マッピング・プロバイダから認可プロバイダにこのロール情報が提供されるので、認可プロバイダは、ロール・ベースのセキュリティを用いるWebLogicリソース(WebアプリケーションやEnterprise JavaBeans (EJB))からの「アクセスできるか」という質問に答えることができます。
裁決 - セキュリティ・レルムに複数の認可プロバイダが構成される場合、特定のリソースに「アクセスできるか」という質問に対して、それぞれが異なる回答を返すことがあります。複数の認可プロバイダの回答が一致しない場合にどうするかを決定するのが、裁決プロバイダの主な役割です。裁決プロバイダは、各認可プロバイダの回答に重みを割り当てることによって認可の競合を解決し、アクセスに関する最終決定を返します。
資格証明マッピング - 資格証明マップとは、WebLogic Serverで使用する資格証明と、レガシー・システムまたはリモート・システムで使用する資格証明とのマッピングです。WebLogic Serverではこのマップによって、そのシステム内の特定のリソースへの接続方法を認識します。つまり、資格証明マップを使用することで、WebLogic Serverが、認証済みのサブジェクトに代わってリモート・システムにログインできるようになります。資格証明マッピング・プロバイダはこのように資格証明をマップします。
キーストア - 秘密キーと信頼された認証局の証明書を格納する、パスワードで保護されたストアの作成と管理のためのメカニズムです。キーストアは、認証や署名を目的としてそれを必要とすることがあるアプリケーションから利用できます。WebLogic Serverのセキュリティ・アーキテクチャでは、WebLogicキーストア・プロバイダを使用してキーストアにアクセスします。

ノート:

WebLogic Serverキーストア・プロバイダは削除されました。後方互換性を保持するためにのみサポートされています。かわりにJDKキーストアを使用してください。キーストア構成の詳細は、「キーストアの作成」を参照してください。
証明書ルックアップおよび検証(CLV) - IDと信頼のために、X.509証明書を検索および検証する必要があります。CLVプロバイダは、証明書、証明書チェーン、または証明書参照を受け取り、証明書パスを完成させ(必要な場合)、パス内のすべての証明書を検証します。CLVプロバイダには、2つのタイプがあります。
- 証明書パス・ビルダーは、証明書パスの検索と完成(必要な場合)、および証明書の検証を行います。
- 証明書パス検証プロバイダは、証明書パスの検索と完成(必要な場合)、証明書の検証、および追加の検証(失効チェックなど)を行います。
証明書レジストリ - 証明書レジストリは、セキュリティ・レルムに証明書失効チェックを追加するためのメカニズムです。証明書レジストリは、有効な証明書のリストを保持します。登録されている証明書のみが有効です。証明書レジストリから削除することによって、その証明書は失効します。このレジストリは、組込みLDAPサーバーに格納されます。証明書レジストリは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。
監査 - セキュリティ・リクエストとその結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスです。言い換えれば、監査はコンピュータのアクティビティの電子的な記録を提供するものです。監査プロバイダは、これらのサービスを提供します。

WebLogicセキュリティ・プロバイダで提供される機能の詳細は、WebLogicセキュリティ・プロバイダの構成についてとWebLogic Serverでの認証プロバイダの構成についてを参照してください。

デフォルトのセキュリティ構成については、「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。

カスタム・セキュリティ・プロバイダの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

セキュリティ・ポリシーとWebLogicリソース

WebLogic Serverは、セキュリティ・ポリシーを使用してWebLogicリソースを保護します。セキュリティ・ポリシーは、WebLogicリソースへの「アクセス権は誰が持つか」という問いに答えます。セキュリティ・ポリシーは、WebLogicリソースとユーザー、グループ、またはセキュリティ・ロールの間の関連付けを定義するときに作成します。また、セキュリティ・ポリシーに時間の制約を関連付けることもできます。WebLogicリソースは、セキュリティ・ポリシーが割り当てられるまでは保護されません。

セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。このプロセスについて理解を深めるには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を読んでください。WebLogic Serverのデプロイメントに対するセキュリティを完全に構成するには、そのドキュメントをWebLogicセキュリティの保護とあわせて使用する必要があります。

この項には次のトピックが含まれます:

WebLogicリソース

WebLogicリソースは、権限のないアクセスから保護することができる基底のWebLogic Serverエンティティを表す構造化オブジェクトです。WebLogic Serverでは、以下のリソースが定義されます。

WebLogicリモート・コンソールやWebLogic Scripting Toolなどの管理リソース。
エンタープライズ・アプリケーションを表すアプリケーション・リソース。このタイプのリソースには、EAR (エンタープライズ・アプリケーション・アーカイブ)ファイルと、EARに含まれるEJB JARファイルのような個々のコンポーネントがあります。
Microsoftのフレームワークに従ってプログラム・コンポーネント・オブジェクトとして設計されるComponent Object Model (COM)リソース。このタイプのリソースには、Oracleの双方向型COM-Java (jCOM)ブリッジング・ツールを介してアクセスするCOMコンポーネントがあります。
リソース・アダプタとして設計されるエンタープライズ情報システム(EIS)リソース。Javaアプリケーションと既存のエンタープライズ情報システムを統合できます。これらのリソース・アダプタは、コネクタとも呼ばれます。
Enterprise JavaBean (EJB)リソース。EJB JARファイル、EJB JAR内の個々のEJB、およびEJBの個々のメソッドがあります。
Java DataBase Connectivity (JDBC)リソース。接続プールのグループ、個々の接続プール、およびマルチプールがあります。
Java Naming and Directory Interface (JNDI)リソース。
Java Message Service (JMS)リソース。
WebLogic Serverインスタンス(サーバー)に関連するサーバー・リソース。このタイプのリソースには、サーバーを起動、停止、ロック、またはロック解除する操作があります。
Webアプリケーションに関連するURLリソース。このタイプのリソースには、Webアプリケーション・アーカイブ(WAR)ファイル、またはWebアプリケーションの個々のコンポーネント(サーブレットやJSPなど)があります。

ノート:

Webリソースは非推奨になりました。かわりにURLリソースを使用してください。
Webベースの分散アプリケーションのコンポーネント間で共有したり、コンポーネントとして使用したりできるサービスに関連したWebサービス・リソース。このタイプのリソースには、Webサービス全体、またはWebサービスの個々のコンポーネント(ステートレス・セッションEJB、そのEJB内の特定のメソッド、web-services.xmlファイルを含むWebアプリケーションなど)があります。
リモート・リソース。

デプロイメント・ディスクリプタおよびWebLogicリモート・コンソール

WebLogicセキュリティ・サービスは、デプロイメント記述子に定義された情報を使用してWebアプリケーションまたはEJBのためにセキュリティ・ロールを付与し、セキュリティ・プロファイルを定義することができます。

WebLogic Serverでは、セキュリティ・ロールおよびポリシーの構成モデルを選択できます。標準のJava Enterprise Editionモデルでは、ロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。WebLogicセキュリティ・サービスは、デプロイメント記述子に定義された情報を使用してWebアプリケーションまたはEJBのためにセキュリティ・ロールを付与し、セキュリティ・プロファイルを定義することができます。WebLogic Serverを最初に起動するときに、web.xml、weblogic.xml、ejb-jar.xml、またはweblogic-ejb-jar.xmlデプロイメント記述子に格納されたセキュリティ・ロールとセキュリティ・ポリシーの情報が、デフォルト・セキュリティ・レルムに構成されている認可プロバイダとロール・マッピング・プロバイダにロードされます。ロールやポリシーの情報は、後からWebLogicリモート・コンソールで確認できます。(必要に応じ、別のセキュリティ・モデルを使用するようにセキュリティ・レルムを構成して、WebLogicリモート・コンソールを使用してこれらの情報を変更できるようにすることも可能です。)

デプロイメント記述子内の情報を利用するには、セキュリティ・レルム内の少なくとも1つの認可プロバイダとロール・マッピング・プロバイダがそれぞれDeployableAuthorizationProviderおよびDeployableRoleProviderセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装している必要があります。このSSPIを使用すると、プロバイダはデプロイメント記述子から情報を(検索ではなく)格納できます。デフォルトでは、WebLogic認可プロバイダとロール・マッピング・プロバイダがこのSSPIを実装しています。

WebLogicリモート・コンソールからデプロイメント記述子内のセキュリティ・ロールとセキュリティ・ポリシーを変更し、それ以降もこの情報をWebLogicリモート・コンソールから変更する予定がある場合は、このコンソールで行った変更がWebLogic Serverの再起動時にデプロイメント記述子の古い情報で上書きされないように、セキュリティ・レルムに構成オプションを設定できます。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のWebアプリケーションおよびEJBリソースの保護のオプションに関する項を参照してください。

WebLogic Serverのデフォルト・セキュリティ構成

WebLogic Serverのセキュリティの構成と管理を簡素化するために、デフォルトのセキュリティ構成が用意されています。デフォルト・セキュリティ構成では、myrealmがデフォルト・セキュリティ・レルムとして設定され、WebLogic裁決、認証、アイデンティティ・アサーション、XACML認可、資格証明マッピング、XACMLロール・マッピング、および証明書パスの各プロバイダがセキュリティ・プロバイダとしてそのレルムに定義されています。WebLogic Serverの組込みLDAPサーバーは、これらのデフォルト・セキュリティ・プロバイダ用のデータ・ストアとして使用されます。デフォルト・セキュリティ構成を使用するには、セキュリティ・レルムでユーザー、グループ、およびセキュリティ・ロールを定義し、セキュリティ・ポリシーを作成してドメイン内のWebLogicリソースを保護する必要があります。

ノート:

WebLogic Serverには、WebLogic認可プロバイダ(WebLogicリモート・コンソールなどではDefaultAuthorizer)、およびWebLogicロール・マッピング・プロバイダ(WebLogicリモート・コンソールなどではDefaultRoleMapper)が組み込まれています。WebLogic Server 9.1から、新しく作成されるセキュリティ・レルムでは、これらのプロバイダはデフォルトのプロバイダではなくなりました。代わりに、XACML認可プロバイダとXACMLロール・マッピング・プロバイダがデフォルトのプロバイダになっています。

DefaultAuthorizerプロバイダとDefaultRoleMapperプロバイダは、WebLogic Server 14.1.1.0.0で非推奨となっており、今後のリリースで削除されます。

WebLogicセキュリティ・プロバイダで提供される機能の詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。これらのWebLogicセキュリティ・プロバイダがセキュリティ要件を必ずしも完全に満たしていない場合には、それらを補うか、あるいは入れ替えることができます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

デフォルト・セキュリティ構成では要件が満たされない場合、WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダを自由に組み合せて新しいセキュリティ・レルムを作成し、そのセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定できます。デフォルト・セキュリティ構成のカスタマイズを参照してください。

WebLogicセキュリティの構成: 主なステップ

WebLogic Serverのセキュリティ機能は互いに関連しているので、セキュリティを構成する場合にどこから始めるべきか判断しにくいものです。実際、WebLogic Serverデプロイメントのセキュリティを構成する場合には、同じ作業を繰り返すこともあります。構成のステップはいくつかありますが、次の手順を実行することをお薦めします。

本番環境でWebLogic Serverを使用する予定がある場合は、必ず次を実行してください。
1. WebLogic Serverをインストールする前にホスト環境を保護します。「WebLogic Serverのセキュア・インストールの実行」の説明に従います。
2. WebLogicドメインを作成するときは、「本番用のWebLogicドメインの作成」の説明に従って、ドメインが本番モードまたは保護された本番モードで実行されるように構成します。
3. 初めてドメインを起動したらすぐに、「ドメイン作成後の保護」のタスクを実行します。
「デフォルト・セキュリティ構成をカスタマイズする理由」に目を通して、デフォルト・セキュリティ構成を使用するかどうかを決定します。
- デフォルト・セキュリティ構成を使用する場合は、ステップ4に進みます。
- デフォルト・セキュリティ構成を使用しない場合は、ステップ3に進みます。
デフォルト・セキュリティ・レルムで、追加のセキュリティ・プロバイダを構成するか(たとえば、WebLogic認証プロバイダを使用するかわりにLDAP認証プロバイダを構成します)、またはカスタム・セキュリティ・プロバイダを構成します。このステップはオプションです。デフォルトでは、WebLogic Serverはデフォルト・セキュリティ・レルム(myrealm)のWebLogicセキュリティ・プロバイダを構成します。デフォルト・セキュリティ構成をカスタマイズする必要がある状況については、「デフォルト・セキュリティ構成をカスタマイズする理由」を参照してください。カスタム・セキュリティ・プロバイダの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の開発プロセスの概要に関する項を参照してください。

ノート:

また、新しいセキュリティ・レルムを作成し、そのセキュリティ・レルムでセキュリティ・プロバイダ(WebLogicまたはカスタム)を構成し、そのセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定することもできます。デフォルト・セキュリティ構成のカスタマイズを参照してください。
必要に応じて、組込みLDAPサーバーを構成します。WebLogic Serverの組込みLDAPサーバーは、デフォルト・オプションで構成されています。ただし、これらのオプションを変更して、組込みLDAPサーバーの使い方を環境に合わせて最適化できます。組込みLDAPサーバーの管理を参照してください。
ユーザー・アカウントが適切に保護されていることを確認します。WebLogic Serverにはユーザー・アカウントを保護するための構成オプションが用意されています。デフォルトでは、属性は最高のセキュリティ・レベルに設定されています。ただし、WebLogic Serverの開発およびデプロイメント時には、ユーザー・アカウントに対する制限の緩和が必要な場合もあります。本番環境に移行する前に、ユーザー・アカウントのオプションが最高の保護レベルに設定されていることを確認してください。新しいセキュリティ・レルムを作成する場合は、ユーザーのロック・アウトのオプションを設定する必要があります。「WebLogic Serverでのパスワードの保護の仕組み」と「ユーザー・アカウントの保護」を参照してください。
セキュリティ・ポリシーでWebLogicリソースを保護します。セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。このプロセスについて理解を深め、WebLogic Serverデプロイメントのセキュリティが完全に構成されていることを確認するには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を読んでください。
WebLogic ServerのIDと信頼を構成します。(このステップはオプションですが、特に本番環境の場合には強くお薦めします。)「キーストアの構成」を参照してください。
WebLogic Serverに対してSSL/TLSを有効にします。(このステップもオプションですが、すべての本番環境で強くお薦めします。)「SSLの設定: 主なステップ」を参照してください。
本番に移行する場合、『Oracle WebLogic Server本番環境の保護』で説明されている追加のセキュリティ・オプションを確認し、実装してください。

また、以下のことを行うことができます。

接続フィルタを構成します。「接続フィルタの使用」を参照してください。
WebLogicドメイン間の相互運用性を有効化します。クロス・ドメイン・セキュリティの構成を参照してください。

セキュリティの構成方法

多くのツールを使用して、WebLogic Serverのセキュリティを構成できます。通常、このドキュメントでは、WebLogicリモート・コンソールを使用して保護を構成する手順について説明しますが、通常は、他の構成ツールを使用しても実行できます。

一般的な構成ツールには、Fusion Middleware Control、WebLogic Scripting Tool (WLST)、REST APIおよびJava Management Extensions (JMX)があります。

使用するツール	参照先のトピック
WLST	『WebLogic Scripting Toolの理解』のセキュリティ・データの管理(WLSTオンライン)に関する項
Fusion Middleware Control	『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の「WebLogic Serverセキュリティ」
REST	『RESTful管理サービスによるOracle WebLogic Serverの管理』の「WLS RESTful管理インタフェースの使用」
JMX API	『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のセキュリティ・レルムを管理するMBeanサーバーの選択に関する項
WebLogicリモート・コンソール	Oracle WebLogic Remote Consoleオンライン・ヘルプのドメインの保護に関する項

セキュリティ・レルムを管理する場合は、タスクに応じて2つの異なるMBeanサーバーを使用する必要があります。

セキュリティMBean属性の値を設定する場合は、編集MBeanサーバーを使用します。
セキュリティ・プロバイダMBeanでユーザー、グループ、ロール、およびポリシーを追加したり、他の操作を呼び出したりする場合は、実行時MBeanサーバーまたはドメイン実行時MBeanサーバーを使用します。

たとえば、DefaultAuthenticatorMBeanのMinimumPasswordLength属性の値は、ドメインの構成ドキュメントに格納されています。このドキュメントに対するすべての変更はWebLogic Serverによって制御されているため、この属性の値を変更するには、編集MBeanサーバーを使用してドメインの構成に対してロックを取得する必要があります。DefaultAuthenticatorMBeanのcreateUser操作は、LDAPサーバーにデータを追加します。この操作はWebLogic Serverによって制御されていません。DefaultAuthenticatorMBeanの構成とそれがLDAPサーバーで使用するデータの間で両立不能な変更が発生しないように、自身や別のユーザーがMinimumPasswordLength属性の変更を行っている場合にはcreateUser操作を呼び出すことはできません。さらに、この属性の変更にはWebLogic Serverの再起動が必要になるため、サーバーが再起動するまでcreateUser操作を呼び出すことができません。

WebLogic Serverでのパスワードの保護の仕組み

埋込みLDAPに格納されているWebLogicドメイン・ユーザー・アカウントの場合、パスワードは復号化できない一方向ハッシュを使用して暗号化されます。外部LDAPシステムまたはRDBMSに格納されているユーザー・アカウントのパスワードは、そのLDAPまたはRDBMSに格納され、それによって管理されます。外部ストアの場合、アルゴリズムは異なる可能性がありますが、ほとんどのLDAPサーバーでは一方向ハッシュが使用され、RDBMSシステムでは構成に応じてハッシュまたは暗号化が使用されます。WebLogicドメインのリソースにアクセスするためのパスワードを保護することは重要です。ユーザー名とパスワードは以前、WebLogicセキュリティ・レルムにクリア・テキストで保存されていました。

ノート:

WebLogic認証プロバイダのWebサービス・パスワード・ダイジェスト機能は、ハッシュされたパスワードを使用しません。パスワード・ダイジェストを実行時に計算できるように、かわりに可逆暗号化が使用されます。(パスワード・ダイジェスト認証は、サーブレットとWebアプリケーションではサポートされていません。)「パスワード・ダイジェストの有効化」属性の詳細は、『Oracle WebLogic Server MBeanリファレンス』のDefaultAuthenticatorMBean.PasswordDigestEnabledに関する項を参照してください。

SerializedSystemIni.datファイルにドメインのプライマリ暗号化キーが含まれます。このファイルは特定のWebLogicドメインに関連付けられるため、ドメイン間で移動することはできません。

JDBCパスワードなどの機密性の高い構成データは、プライマリ暗号化キーを使用して暗号化されます。こうして暗号化されたデータはconfig.xmlに保存されます。または、埋込みLDAPのセキュリティ・メタデータ/ポリシー・ストアに保存されます。(構成されている場合はRDBMSが使用されます。)

SerializedSystemIni.datファイルが破損した場合、リカバリすることはできません。既存のWebLogicドメインを削除して新しいドメインを作成する必要があります。そのため、次の注意事項を考慮する必要があります。

SerializedSystemIni.datファイルのバックアップを作成し、安全な場所に保管します。
WebLogic Serverデプロイメントのシステム管理者が読み書き権限を持ち、その他のユーザーは何の権限も持たないように、SerializedSystemIni.datファイルに権限を設定します。