ドメインの保護

WebLogic Serverは、認可されていないアクセスからWebLogic Server環境を保護するための堅牢なセキュリティ・ツール・セットを提供します。 WebLogic Remote Consoleを使用してシステムを保護します。

WebLogic Serverのセキュリティ概念の一般情報は、次を参照してください:

潜在的なセキュリティ問題に対処

WebLogic Serverは、ドメインが推奨されるセキュリティ・ポリシーに準拠していることを定期的にチェックします。ドメインが推奨事項を満たさない場合、セキュリティ警告が記録され、WebLogic Remote Consoleに表示されます。

ドメインにアクティブなセキュリティ警告がある場合、WebLogic Remote Consoleウィンドウの上部に赤いバナーが表示されます。セキュリティの問題が解消されるまで残ります。

セキュリティ警告をトリガーする可能性のある問題の詳細は、「Oracle WebLogic Serverの本番環境の保護」の「潜在的なセキュリティ問題のレビュー」を参照してください。

ドメインのセキュリティを判断するために、セキュリティ警告レポートだけに依存しないでください。これらのセキュリティ構成設定は、潜在的なセキュリティの問題に幅広く対応していますが、警告が発生しない他のセキュリティの問題がドメイン内にまだ存在している可能性があります。

ノート

WebLogic Server 14.1.1.0以前を実行している環境では、セキュリティ警告を表示するには、2021年7月のパッチ・セット更新(PSU)が必要です。

「セキュリティ警告」バナーで、「レポートの表示/リフレッシュ」をクリックして、フラグが付けられた問題を確認します。

「モニタリング」パースペクティブ、「環境」、「ドメイン・セキュリティ・ランタイム」の順に選択して、「セキュリティ警告」ページに移動することもできます。
問題の摘要をレビューして、セキュリティ警告を理解してください。
「解決情報」に示されているステップに従って、問題を解決します。

同じ問題が、ドメイン内の複数のサーバーに同時に影響を及ぼす可能性があります。影響を受けるすべてのサーバーで問題を修正してください。

特定のポリシーが環境に適用されない、またはビジネス・ニーズにあわせて実装できないと思われる場合は、JDKの最小バージョン・チェックを除いて、個々のセキュリティ・チェックを無効にできます。
必要に応じて、サーバーを再起動して修正を適用し、セキュリティ警告をクリアします。

セキュリティ警告の修正

セキュリティ警告に関する最新情報および解決の推奨ステップについては、My Oracle Supportの記事「WebLogic Server Security Warnings (ドキュメントID 2788605.1)」を参照してください。

ノート

同じ問題が、ドメイン内の複数のサーバーに同時に影響を与える可能性があります。セキュリティ警告レポートを確認する際には、影響を受けるすべてのサーバーで問題を修正してください。問題とその解決策によっては、セキュリティ警告レポートを更新するためにサーバーを再起動することが必要な場合があります。

セキュリティ・レルム

セキュリティ・レルムは、WebLogic Serverリソースを保護するように設計されたメカニズムの集合です。各セキュリティ・レルムには、一連の構成済セキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーが含まれています。ユーザーはセキュリティ・レルムで定義されていないと、そのセキュリティ・レルムに属するWebLogicリソースにアクセスできません。

詳細は、「Oracle WebLogic Serverのセキュリティの理解」の「セキュリティ・レルム」を参照してください。

WebLogic Serverは、事前構成されたセキュリティ構成で、新しい各ドメインをセキュリティ・レルムでプロビジョニングします。 「Oracle WebLogic Serverのセキュリティの管理」の「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。

デフォルトのセキュリティ構成が要件を満たさない場合は、カスタム設定およびプロバイダを使用して新しいセキュリティ・レルムを作成し、それをデフォルトのセキュリティ・レルムとして設定できます。 「Oracle WebLogic Serverのセキュリティの管理」の「デフォルト・セキュリティ構成のカスタマイズ」を参照してください。

ノート

WebLogic Serverを設定すると、WebLogic Serverを再起動せずに、非動的変更をセキュリティ・レルムにただちに適用できます。「レルムの自動再起動の有効化」を参照してください。

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

セキュリティ・レルムを有効にするには、次のセキュリティ・プロバイダを構成する必要があります:

認証プロバイダ
認可プロバイダ
裁決プロバイダ
資格証明マッピング・プロバイダ
証明書パス・プロバイダ
ロール・マッピング・プロバイダ

WebLogic Serverには、必要な各セキュリティ・プロバイダのデフォルト・オプションと、デフォルト・プロバイダがニーズに合わない場合は代替オプションが含まれます。独自のカスタム・プロバイダを作成することもできます。

セキュリティ・レルムの作成

セキュリティ・レルムは、ドメインのセキュリティ構成を編成します。

新しいセキュリティ・レルムを作成する前に、「Oracle WebLogic Serverのセキュリティの管理」の「新しいセキュリティ・レルムを作成する前に」で概説されている考慮事項を確認してください。

「編集ツリー」で、「セキュリティ」、「レルム」の順に移動します。
「新規」をクリックします。
新しいセキュリティ・レルムの名前を入力します。
WebLogic Serverで必要なセキュリティ・プロバイダをセキュリティ・レルムに追加して、新しいセキュリティ・レルムが有効であることを確認する場合は、「デフォルト・プロバイダの作成」オプションを有効にします。

デフォルト・プロバイダを変更することも、必要に応じて別のプロバイダに置き換えることもできます。

ノート
「デフォルト・プロバイダの作成」を有効にしない場合は、新しいセキュリティ・レルムをコミットする前に、必要なセキュリティ・プロバイダを手動で構成する必要があります。必要なセキュリティ・プロバイダのリストは、「必要なセキュリティ・プロバイダ」を参照してください。
「作成」をクリックします。

デフォルト・セキュリティ・レルムの変更

WebLogic Serverを構成して、デフォルトのセキュリティ構成をカスタム・セキュリティ・レルムに置き換えることができます。

ノート

元のデフォルトのセキュリティ構成はカスタマイズできますが、Oracleでは、完全に新しいセキュリティ・レルムを作成し、そこでセキュリティ構成を変更することをお薦めします。これにより、必要に応じて、元のデフォルトのセキュリティ構成に簡単に戻すことができます。

まだ作成していない場合は、新しいセキュリティ・レルムを作成します。「セキュリティ・レルムの作成」を参照してください。
「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブを選択します。
「デフォルト・レルム」ドロップダウン・リストから、デフォルトにするセキュリティ・レルムを選択します。
「保存」をクリックします。

必要に応じて以前のセキュリティ構成に戻すことができるように、構成アーカイブを有効にして以前のドメイン構成を保存することを検討してください。「構成ファイルのバックアップ」を参照してください。

以前のセキュリティ構成に戻す

新しいセキュリティ・レルムまたはセキュリティ・プロバイダを構成すると、サーバーのブートが妨げられる場合があります。これが発生した場合は、構成XMLファイルを元に戻して、以前のレルム構成を回復し、エラーからリカバリできます。

以前の構成に戻すことができるのは、構成のアーカイブが有効で、以前のバージョンの構成を保存している場合のみです。「構成ファイルのバックアップ」を参照してください。

また、WLSTオフラインを使用して、サーバーのブートを妨げるエラーを修正することもできます。

ノート

このプロセスでは、レルムで使用されるユーザー、グループ、ロールまたはセキュリティ・ポリシーではなく、セキュリティ・レルム(つまり、レルムとそのプロバイダの構成)のみが元に戻されます。このポリシーは、構成ファイルではなくデータ・ストアに保持されます。

元に戻すセキュリティ構成を含むconfig.jarファイルを探し、一時ディレクトリにコピーして解凍します。
解凍した構成ファイルをDOMAIN_HOME/configディレクトリ内の適切なロケーションにコピーします。どのディレクトリがどの構成ファイルを保持するかの詳細は、「Oracle WebLogic Serverのドメイン構成の理解」の「ドメイン・ディレクトリの内容」を参照してください。
WebLogic Serverを再起動します。

レルムの自動再起動の有効化

WebLogic Serverを設定すると、WebLogic Serverを再起動せずに、非動的変更をセキュリティ・レルムにただちに適用できます。

デフォルト・セキュリティ・レルムでは、レルムの自動再起動がデフォルトで無効になっています。作成する「新規」セキュリティ・レルムでは、レルムの自動再起動はデフォルトで「有効」です。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「レルムの自動再起動の使用」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealmの順に移動します。
「動的以外の変更後に自動的に再起動」オプションを有効にします。
「保存」をクリックします。

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

WebLogicセキュリティ・サービスは、複数のセキュリティ・プロバイダを含む様々なセキュリティ・アーキテクチャをサポートします。

WebLogicセキュリティ・レルムのセキュリティ・プロバイダを構成する前に、WebLogic Securityサービスの仕組みや、ご使用のWebLogic環境に必要なセキュリティ・アーキテクチャのタイプについて理解しておく必要があります。参照:

「Oracle WebLogic Serverのセキュリティの理解」の「WebLogicセキュリティ・サービスの概要」
「Oracle WebLogic Serverのセキュリティの管理」の「セキュリティ・プロバイダの構成」。
「Oracle WebLogic Serverのセキュリティ・プロバイダの開発」の「WebLogic Serverのセキュリティ・プロバイダの開発の概要」。
「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「WebLogicリソース・セキュリティの理解」。

セキュリティ・アーキテクチャは、WebLogic Serverに含まれるデフォルト・セキュリティ・プロバイダ、サード・パーティが開発したセキュリティ・プロバイダ、または自分で開発したカスタム・セキュリティ・プロバイダの組合せで構成できます。

セキュリティ・プロバイダのタイプは次のとおりです。

認証プロバイダ
IDアサーション・プロバイダ
認可プロバイダ
裁決プロバイダ
ロール・マッピング・プロバイダ
資格証明マッピング・プロバイダ
監査プロバイダ

認証プロバイダまたはアイデンティティ・アサーション・プロバイダの構成

認証プロバイダを使用して、ユーザーまたはシステム・プロセスのアイデンティティを証明します。 WebLogic認証プロバイダおよびWebLogicアイデンティティ・アサーション・プロバイダはデフォルトで有効になっていますが、必要に応じて追加の認証プロバイダまたはIDアサーション・プロバイダを構成できます。

WebLogic Serverに含まれる認証プロバイダおよびアイデンティティ・アサーション・プロバイダの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「認証プロバイダの選択」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「認証プロバイダ」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、認証プロバイダのタイプを選択します。
「作成」をクリックします。
新しい認証プロバイダの「構成」ページで、「共通」および「プロバイダ固有のパラメータ」タブで適切な値を設定します。
「保存」をクリックします。

パスワード・バリデーション・プロバイダは、新しいWebLogicドメインを構成した直後に構成することをお薦めします。 WebLogic Serverに付属するパスワード・バリデーション・プロバイダは、パスワード構成ルールを管理および実施するために、即時利用可能な複数の認証プロバイダで構成できます。セキュリティ・レルムでパスワードが作成または更新されるたびに、対応する認証プロバイダによってパスワード・バリデーション・プロバイダが自動的に起動され、パスワードが確立された構成要件を満たしていることが確認されます。詳細については、「パスワード・バリデーション・プロバイダの構成」を参照してください。

JAAS制御フラグの設定

ドメインに複数の認証プロバイダがある場合は、JAAS制御フラグを使用して、各認証プロバイダがログイン順序でどのように使用されるかを制御します。

WebLogic Serverによる複数の認証プロバイダの処理方法の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「複数の認証プロバイダの使用」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」の順に移動し、変更するセキュリティ・レルムを選択します。
「認証プロバイダ」ノードを展開し、構成する認証プロバイダを選択します。
「管理フラグ」ドロップダウン・リストからオプションを選択します:
- 必須
- 要件
- 十分
- オプション各値の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「JAAS制御フラグ・オプションの設定」を参照してください。
「保存」をクリックします。
ドメイン内の残りの認証プロバイダについても繰り返します。

認可プロバイダの構成

認可プロバイダを使用して、リソースへのアクセス権を持つユーザーを決定します。

認可プロバイダの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「認可プロバイダの構成」を参照してください。

ノート

WebLogic認可プロバイダは、WebLogic Server 14.1.1.0.0で非推奨になり、将来のリリースで削除されます。 XACML認可プロバイダがデフォルト・プロバイダです。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「承認者」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、認可プロバイダのタイプを選択します。
「作成」をクリックします。
新しい「認可プロバイダ」ページで、目的の値を設定します。
「保存」をクリックします。

WebLogic裁決プロバイダの構成

裁決プロバイダは、各認可プロバイダのアクセス決定の重み付けを行い、リクエストされたリソースへのアクセスを許可するかどうかを決定することで、認可の衝突を解決します。

セキュリティ・レルムで構成された認可プロバイダが1つのみで、それがWebLogic認可プロバイダである場合、単一の認可プロバイダから返されたABSTAINはDENYとして扱われます。

各セキュリティ・レルムには、裁決プロバイダが1つのみ必要です。

WebLogic Serverは、WebLogicセキュリティ・フレームワークに対して1つの裁決プロバイダを提供: WebLogic裁決プロバイダ。 WebLogic Remote Consoleは、WebLogic裁決プロバイダをデフォルト裁決プロバイダと呼びます。

裁決プロバイダの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「WebLogic裁決プロバイダの構成」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「裁決者」の順に移動します。
「作成」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、裁決プロバイダのタイプを選択します。
「作成」をクリックします。
新しい裁決プロバイダ・ページで、「デフォルト裁決パラメータ」タブで適切な値を設定します。
「保存」をクリックします。

ロール・マッピング・プロバイダの構成

ロール・マッピングとは、実行時にプリンシパル(ユーザーまたはグループ)をセキュリティ・ロールに動的にマップするプロセスのことです。ロール・マッピング・プロバイダは、サブジェクトがWebLogicリソースに対して操作を実行しようとしたときに、サブジェクトに格納されているプリンシパルに適用されるセキュリティ・ロールを決定します。

通常、これらの操作にはWebLogicリソースへのアクセスが含まれるため、ロール・マッピング・プロバイダは通常、認可プロバイダで使用されます。

ノート

WebLogicロール・マッピング・プロバイダは、WebLogic Server 14.1.1.0.0で非推奨となり、将来のリリースで削除されます。 XACMLロール・マッピング・プロバイダがデフォルト・プロバイダです。

ロール・マッピング・プロバイダの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「ロール・マッピング・プロバイダの構成」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「ロール・マッパー」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、ロール・マッピング・プロバイダのタイプを選択します。
「作成」をクリックします。
新しい「ロール・マッピング・プロバイダ」ページで、必要に応じて値を更新します。
「保存」をクリックします。

監査プロバイダの構成

監査プロバイダは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布します。

監査プロバイダはセキュリティ・レルムで複数を構成できますが、必須ではありません。デフォルト・セキュリティ・レルムには監査プロバイダは含まれていません。

WebLogic監査プロバイダは、WebLogicセキュリティ・フレームワークの標準監査プロバイダです。 WebLogic Remote Consoleは、WebLogic監査プロバイダをデフォルト監査プロバイダと呼びます。

構成アクションを監査するようにWebLogic Serverを構成することもできます。「構成監査の有効化」を参照してください。

監査プロバイダの詳細は、「WebLogic監査プロバイダの構成」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「監査役」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「作成」をクリックします。
新しい「監査プロバイダ」ページで、「デフォルト監査者パラメータ」タブで適切な値を設定します。
「保存」をクリックします。

資格証明マッピング・プロバイダの構成

資格証明マッピング・プロバイダを使用することで、WebLogic Serverは認証済みのサブジェクトになり代わってリモート・システムにログインできるようになります。セキュリティ・レルムには1つの資格証明マッピング・プロバイダが必要です。1つのセキュリティ・レルムに複数の資格証明マッピング・プロバイダを構成することもできます。

資格証明マッピング・プロバイダの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「資格証明マッピング・プロバイダの構成」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「資格証明マッパー」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、資格証明マッパーのタイプを選択します。
「作成」をクリックします。
新しい資格証明マッピング・プロバイダ・ページで、必要に応じて「デフォルトの資格証明マッパー・パラメータ」タブの値を更新します。
「保存」をクリックします。

資格証明マッピング・プロバイダを構成したら、資格証明をWebLogicリソースにマップできます。次のWebLogic Serverリソースの資格証明マッピングを作成できます:

アプリケーション・デプロイメント
- EJB
- JDBCアプリケーション
- リソース・アダプタ
データ・ソース
リモート・リソース

一般的なプロセスは次のとおりです:

「ツリーの編集」で、MBeanを構成します。変更を確定してから、必要に応じてサーバーを再起動します。
「セキュリティ・データ・ツリー」の「資格証明マッパー」で、構成したMBeanに対応するノードを見つけます。 WebLogicリソースのプロパティを定義して識別し、MBeanの構成データとそのセキュリティ・データ間の接続を形成することが必要な場合があります。「資格証明マッピングのリソースを特定」を参照してください。
WebLogicリソースのマッピングを作成します。

資格証明マッピングのリソースを特定

特定のWebLogicリソースでは、そのMBean構成データとそのセキュリティ・データとの間の接続を手動で形成する必要があります。

ノート

このプロセスの一環として、リソースの最初の資格証明マッピングを作成します。

マッピングを追加する前に、WebLogicリソースを構成する必要があります。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」の順に移動します。
資格証明マッピング用に準備するWebLogicリソースに到達するまで続行します。

例えば:
- EJBコンポーネント・ノードは資格証明マッパーの下に表示されます: credentialMappingProvider: アプリ・デプロイメント: applicationName: EJBs
- リソース・アダプタ・ノードが資格証明マッパーの下に表示されます: credentialMappingProvider: アプリ・デプロイメント: applicationName: リソース・アダプタ
- リモート・リソースが資格証明マッパーの下に表示されます: credentialMappingProvider: リモート・リソース。データ・ソースを識別する必要はありません。
「新規」をクリックし、必要に応じてフィールドに入力します。
「作成」をクリックします。

リソースへの参照がリソースのノードの下に追加されます。リソースの名前は、そのプロパティ値を組み合わせて生成されます。

複数の資格証明マッピングを持つリソースへの参照は削除できません。リソース参照を削除するには、まずすべての資格証明マッピングを削除する必要があります - これにより、リソース参照が自動的に削除されます。

資格証明マッピングの追加

新しい資格証明マッピングを追加して、別のWebLogicリソースをリモート・ユーザーに関連付けることができます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、credentialMappingProvider、wlResourceType、wlResourceName、「資格証明マッピング」の順に移動します。
「新規」をクリックします。
必要に応じて、各フィールドに入力します。

ノート
リモート・リソースですでに参照されているリモート・ユーザーにマップする場合は、「資格証明の作成」オプションを無効にします。
「作成」をクリックします。

各WebLogicリソースの資格証明マッピングおよび資格証明は、リソースのノードの下に表示されます。

資格証明マッピングを削除すると、WebLogicリソースが以前に関連付けられたリモート・ユーザーも、そのリモート・ユーザーを使用する唯一の資格証明マッピングだった場合、削除されます。

WebLogicリソースの再マップ

資格証明マッピングを編集して、WebLogicリソースのWebLogicユーザーを別のリモート・ユーザーに関連付けることができます。

WebLogic Serverユーザーを再マップするには、WebLogic Remote Consoleがリモート・ユーザーをすでに認識している必要があります。 WebLogicリソースを新しいリモート・ユーザーに再マップする場合は、まずWebLogic Remote Consoleに追加する必要があります。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、credentialMappingProvider、wlResourceType、wlResourceName、「資格証明マッピング」の順に移動します。
編集する資格証明マッピングを選択します。
「リモート・ユーザー」フィールドで、現在のリモート・ユーザーのユーザー名を、WebLogicリソースを再マップするリモート・ユーザーのユーザー名に置き換えます。
「保存」をクリックします。

資格証明セットの追加

リモート・システムの最初の資格証明セットをWebLogicリソースに追加した後、そのリモート・システムからさらにユーザーを追加できます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、credentialMappingProvider、wlResourceType、wlResourceName、「資格証明」の順に移動します。
「新規」をクリックします。
リモート・ユーザーのユーザー名とパスワードを入力します。
「作成」をクリックします。

これで、WebLogicリソースのWebLogicユーザーを新しい資格証明セットにマップできます。

ノート

リモート・ユーザーのパスワードが変更された場合、WebLogic Remote Consoleでパスワードを更新する必要があります。更新しないと、マッピングが中断され、WebLogicリソースがリモート・システムにログインできなくなります。

資格証明セットの削除

各WebLogicリソースには、独自の資格証明セットがあります。 WebLogic Remote Consoleから資格証明セットを削除しても、リモート・システムのユーザーには影響しません。

現在WebLogicリソースがマップされている資格証明は削除できません。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、credentialMappingProvider、wlResourceType、wlResourceName、「資格証明」の順に移動します。
削除する資格証明のセットにアクティブな資格証明マッピングがある場合は、次のいずれかを実行できます:
- 関連するマッピングを選択し、「リモート・ユーザー」フィールドを新しいリモート・ユーザーに更新します。
- 関連付けられた資格証明マッピングをすべて削除します。この資格証明セットに関連付けられているすべての資格証明マッピングが削除されると、資格証明自体も自動的に削除され、残りのステップをスキップできます。
同じWebLogicリソースで、「資格証明」ノードを展開します。
資格証明のセットを削除します。
「保存」をクリックします。

証明パス・プロバイダの構成

証明書パス・プロバイダは、信頼性のあるCAに基づいたチェック機能を使用して、証明書チェーンを完了および検証します。

プロバイダはチェーン内の署名をチェックして、チェーンが期限切れでないことを確認し、チェーン内のいずれかの証明書がサーバーの信頼性のあるCAによって発行されたものであることを確認します。いずれかのチェックが失敗した場合、そのチェーンは有効ではありません。必要に応じて、プロバイダは証明書チェーンの基本的な制約をチェックします。

WebLogic Serverの証明書バリデーションの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「証明書検索およびバリデーション・フレームワークの構成」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「証明書パス・プロバイダ」の順に移動します。
「新規」をクリックします。
「名前」フィールドに、新しいプロバイダの名前を入力します。
「タイプ」ドロップダウン・リストから、証明書参照およびバリデーション(CLV)プロバイダのタイプを選択します。
「作成」をクリックします。
このCLVプロバイダをこのレルムの証明書チェーンの現在のビルダーにする場合は、次のステップを実行します:
1. 「編集ツリー」で、「セキュリティ」、「レルム」、myRealmの順に移動します。
2. 「証明書パス・ビルダー」タブで、「証明書パス・ビルダー」ドロップダウン・リストからCLVプロバイダを選択します。
3. 「保存」をクリックします。

パスワード・バリデーション・プロバイダの構成

パスワード検証プロバイダをセキュリティ・レルムで構成すると、そのレルムでユーザーのパスワードが作成または変更されるときに必ず、サポートされる認証プロバイダによって自動的に起動されます。パスワード検証プロバイダがチェックを実行し、パスワードが作成ルールによって設定された基準を満たすかどうかを判別します。それによってパスワードが受入れまたは拒否されます。

パスワード・バリデーション・プロバイダに対して構成できるパスワード構成ルールは次のとおりです:

ユーザー名ポリシー。ユーザー名と同じパスワードを使用できるかなど。
パスワード文字数ポリシー。最小文字数または最大文字数など。
文字ポリシー。各パスワードに必要な英字、数字、記号の最小文字数または最大文字数など。

パスワードには、最初の文字として中カッコ{を含めることはできません。

ノート

デフォルト認証プロバイダがセキュリティ・レルムで構成されている場合は、デフォルト認証プロバイダとパスワード・バリデーション・プロバイダの両方で、最小パスワード長の設定が一貫していることを確認してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「パスワード・バリデータ」の順に移動します。
「新規」をクリックします。
パスワード・バリデータの名前を入力します。
「作成」をクリックします。
作成したパスワード・バリデータの構成ページで、「システム・パスワード・バリデータのパラメータ」タブを選択します。
構成オプションを使用して、許容可能なパスワードの条件を決定します。
「保存」をクリックします。

カスタム・セキュリティ・プロバイダの構成

WebLogic Serverによって提供されるセキュリティ・プロバイダが環境のニーズを満たさない場合は、独自のカスタム・セキュリティ・プロバイダを設計できます。

カスタム・セキュリティ・プロバイダを作成します。ガイダンスは、「Oracle WebLogic Serverのセキュリティ・プロバイダの開発」の「WebLogic Serverのセキュリティ・プロバイダの開発の概要」を参照してください。
カスタム・プロバイダのMBean JARファイルをWL_HOME/server/lib/mbeantypesディレクトリに配置します。
WLSTまたはWebLogic Server RESTful管理インタフェースを使用して、カスタム・セキュリティ・プロバイダをドメインのセキュリティ・レルムに追加します。
ノート
- デプロイ可能な認可プロバイダを追加し、プロバイダがパラレル・セキュリティ・ポリシーをサポートしていない場合は、RealmMBean.DeployableProviderSynchronizationEnabled属性をtrueに設定します。次に、RealmMBean.DeployableProviderSynchronizationTimeout属性にタイムアウト値(ミリ秒)を入力するか、デフォルト値を受け入れます。
- デプロイ可能なロール・マッピング・プロバイダを追加していて、プロバイダがロール変更をサポートしていない場合は、RealmMBean.DeployableProviderSynchronizationEnabled属性をtrueに設定します。次に、RealmMBean.DeployableProviderSynchronizationTimeout属性にタイムアウト値(ミリ秒)を入力するか、デフォルト値を受け入れます。
詳細は、「Oracle WebLogic Serverのセキュリティ・プロバイダの開発」の「カスタム認可プロバイダのスレッドは安全ですか。」または「カスタム・ロール・マッピング・プロバイダのスレッドは安全ですか。」を参照してください。

カスタム・セキュリティ・プロバイダをセキュリティ・レルムに追加した後、WebLogic Remote Consoleを使用して、カスタム・セキュリティ・プロバイダの継承された標準属性を構成および管理できます。ただし、WebLogic Remote Consoleを使用して、MDFファイルのカスタム属性を管理することはできません。

組込みLDAPサーバーの構成

組込みLDAPサーバーには、ユーザー、グループ、グループ・メンバーシップ、セキュリティ・ロール、セキュリティ・ポリシー、および資格証明マップ情報が格納されます。デフォルトでは、各WebLogic Serverドメインに、各属性のデフォルト値が構成されている組込みLDAPサーバーが1つあります。

WebLogicの認証、認可、資格証明マッピング、およびロール・マッピングの各プロバイダでは、データベースとして組込みLDAPサーバーを使用します。新しいセキュリティ・レルムでこれらのプロバイダを使用する場合は、組込みLDAPサーバーのデフォルト値を変更して、環境に合せて最適化できます。

「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブで、「組込みLDAP」サブタブを選択します。
環境に応じて値を更新します。

組込みLDAPサーバーのバックアップ設定の更新を検討してください。具体的には、「バックアップ時間」、「バックアップ分」および「バックアップ・コピー」です。 WebLogic Serverによる組込みLDAPサーバーのデータのバックアップ方法の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「バックアップとリカバリ」を参照してください。
「保存」をクリックし、変更をコミットします。
サーバーを再起動します。

ノート

WebLogicセキュリティ・プロバイダは、組込みLDAPサーバーにデータを格納します。 WebLogicセキュリティ・プロバイダを削除しても、組込みLDAPサーバーのセキュリティ・データは自動的には削除されません。そのプロバイダを再び使用するときのために、セキュリティ・データは組込みLDAPサーバーに残ります。外部LDAPブラウザを使用して、組込みLDAPサーバーのセキュリティ・データを削除してください。

ユーザーとグループ

WebLogic Serverでは、ユーザーおよびグループを使用してリソースへのアクセスを制御します。

ユーザーは、セキュリティ・レルムで認証できるエンティティです。ユーザーになれるのは、アプリケーションのエンド・ユーザーなどの人、クライアント・アプリケーションなどのソフトウェア・エンティティ、またはWebLogic Serverの他のインスタンスです。認証の結果、ユーザーにアイデンティティまたはプリンシパルが割り当てられます。各ユーザーに、セキュリティ・レルムの中において一意のIDが与えられます。ユーザーは、セキュリティ・ロールに関連付けられたグループに入れることも、セキュリティ・ロールに直接関連付けることもできます。

グループは、論理的に整理されたユーザーの集合です。ユーザーは、その職務に応じて、WebLogicリソースに対する様々なレベルのアクセス権を持つグループにまとめられます。グループを管理する方が、多くのユーザーを個々に管理するよりも効率的です。すべてのユーザーおよびグループ名は、セキュリティ・レルム内で一意である必要があります。

詳細は、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「ユーザー、グループおよびセキュリティ・ロール」を参照してください。

WebLogic Remote Consoleは、デフォルトの認証プロバイダ(WebLogic認証プロバイダ)内のユーザーおよびグループのみを追加、編集または削除できます。必要なWebLogic Server APIをサポートする別の認証プロバイダを使用している場合は、WebLogic Remote Consoleでそのユーザーおよびグループを表示できますが、それらを管理するには、プロバイダ固有の外部ツールを使用する必要があります。必要なWebLogic Server APIをサポートしていないプロバイダは、セキュリティ・データ・ツリーに表示されません。

ユーザーの作成

WebLogic認証プロバイダにユーザーを追加できます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」、DefaultAuthenticator、「ユーザー」の順に移動します。
「新規」をクリックします。
ユーザーの「名前」、「説明」および「パスワード」を入力します。

ユーザー名はセキュリティ・レルム内で一意で、パスワードは8文字以上である必要があります。
「作成」をクリックします。
新しいユーザーをグループに追加する場合は、「メンバーシップ」タブで、「使用可能」セクションの下にあるグループを選択し、「選択済」セクションに移動します。

ユーザー・グループは、同じ職責で複数のユーザーを管理するための効率的な方法を提供します。

グループの作成

WebLogic認証プロバイダにグループを追加できます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」、DefaultAuthenticator、「グループ」の順に移動します。
「新規」をクリックします。
グループの「名前」 (およびオプションで「説明」)を入力します。

グループ名はセキュリティ・レルム内で一意である必要があります。
「作成」をクリックします。

グループを別のグループにネストして、ポリシーを継承させることができます。 「メンバーシップ」タブで、グループを「使用可能」から「選択済」に移動すると、現在のグループが「選択済」グループの下にネストされます。

ユーザーまたはグループのフィルタ

認証プロバイダに多数のユーザーまたはグループがある場合は、フィルタを適用することで、表示されるユーザーまたはグループを減らすことができます。フィルタ基準に一致するユーザーまたはグループのみが表示されます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」、myAuthenticationProviderの順に移動します。
「ユーザー」ノードまたは「グループ」ノードのいずれかをクリックします。ユーザーとグループを同時にフィルタすることはできません。
「フィルタ」をクリックし、「名前フィルタ」フィールドに一致基準を入力します。

フィルタは、入力した値に対してexact一致を実行します。一致基準を「含む」するすべてのユーザーまたはグループに一致させる場合は、ワイルドカード文字*を追加して検索を展開します。

例えば:
- Deployと入力しても、デプロイヤ・グループは返されません。かわりに、DeployersまたはDeploy*を使用してデプロイヤ・グループを表示します。
- デフォルト・オーセンティケータ(WebLogic認証プロバイダ)のみ: 一致基準に2つの*文字を追加できます。 adminと入力すると、AdminChannelUsers、Administrators、sysadminなど、文字列adminを含むユーザーまたはグループが返されます。一致では大文字と小文字が区別されません。
「完了」をクリックします。

フィルタは、クリアするか、WebLogic Remote Consoleを再起動するまで保持されます。フィルタがアクティブな場合は、その条件がページの上部に表示されます。フィルタを削除し、すべてのユーザーまたはグループを表示するには、「フィルタ」をクリックし、「名前フィルタ」フィールドに*と入力します。

ユーザー・ロックアウト属性の設定

WebLogic Serverがアカウントをロックする前に、同じユーザー・アカウントでログインを試行できる回数を制御できます。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「WebLogic Serverでのパスワードの保護方法」および「ユーザー・アカウントの保護」を参照してください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealmの順に移動します。
「ユーザー・ロックアウト」タブで、「ロックアウト使用可能」オプションをオンにします。
「ロックアウトしきい値」フィールドで、ユーザー・アカウントがロックされるまでに許可する無効なユーザー・ログイン試行の最大数を設定します。
必要に応じて、追加のユーザー・ロックアウト属性を変更します。
「保存」をクリックします。

ユーザーのロック解除

サーバー単位でのログイン試行が過度に失敗したためにロックされたユーザー・アカウントをロック解除できます。

「モニタリング・ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
「セキュリティ」、「レルム・ランタイム」、myRealmの順に移動します。
「ユーザーのロック解除」をクリックします。
ロックされたユーザー・アカウントのユーザー名を入力します。ドメインに適用可能な場合は、アイデンティティ・ドメインを入力することもできます。
「完了」をクリックします。

ユーザーおよびグループの表示

認証プロバイダを構成した後、プロバイダが必要なWebLogic Server APIをサポートしている場合は、そのユーザーおよびグループをWebLogic Remote Consoleで表示できます。 WebLogic Remote Consoleは、一度に最大1000人のユーザーまたはグループを表示します。グループ・メンバーシップを表示できません。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」の順に移動します。
ユーザーおよびグループを表示する認証プロバイダを選択します。
「ユーザー」ノードまたは「グループ」ノードを展開して、ユーザーおよびグループを表示します。

デフォルトの認証プロバイダ(WebLogic認証プロバイダ)の「のみ」では、ユーザーおよびグループを追加、変更または削除することもできます。

セキュリティ・ポリシーとロール

セキュリティ・ポリシーを使用して、WebLogic Serverドメイン内のリソースにアクセスできるユーザーを管理します。

リソースとは、エンティティ(Webサービスやサーバー・インスタンスなど)またはアクション(WebLogic Server内のメソッドやサーバー・インスタンスを停止する操作など)です。リソース・タイプのリストは、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「ポリシーで保護できるリソース・タイプ」を参照してください。

セキュリティ・ポリシーは、一連の条件に従って、リソースにアクセスできるユーザー、グループまたはロールを指定します。可能な場合は常に、セキュリティ・ロールを使用してアクセス制御を決定する必要があります。セキュリティ・グループなどのセキュリティロールによって、ユーザーにアイデンティティが付与されます。ただしグループとは違い、ロールのメンバーシップは実行時に評価される条件群に基づいて動作できます。

ほとんどのタイプのWebLogicリソースでは、WebLogic Remote Consoleを使用して、アクセスを制限するセキュリティ・ポリシーおよびロールを定義できます。 WebアプリケーションおよびEJBリソースの場合、デプロイメント記述子を使用することもできます。

WebLogicリソースを保護する一般的なプロセスは次のとおりです:

ユーザーとグループを作成します。
デフォルトのセキュリティ・ロールを管理するか、新しいセキュリティ・ロールを作成します。ロールを使用して、(ユーザーまたはグループではなく)WebLogicリソースを保護し、多くのユーザーと連携する管理者の効率を高めることをお薦めします。 WebLogic Serverが提供するデフォルトのロールを使用することも、独自のものを作成することも可能です。
セキュリティ・ポリシーを作成して適用します。

詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

セキュリティ・ロール

セキュリティ・ロールは、特定の条件に基いてユーザーまたはグループに付与されるIDです。複数のユーザーまたはグループに同じセキュリティ・ロールを付与でき、ユーザーまたはグループに複数のロールを割り当てることができます。セキュリティ・ロールは、ポリシーによってWebLogicリソースへのアクセスを制御するために使用されます。

WebLogic Serverには、任意のポリシーで使用できるデフォルトのロール・セットが用意されています。これらはグローバル・ロールと呼ばれ、デフォルトのグローバル・ロールがニーズを満たさない場合は、独自のロールを作成できます。

特定のリソースのポリシーによってのみ使用されるロールを作成することもできます。これらはスコープ指定ロールと呼ばれます。たとえば、機密性の高いビジネス・ロジックを含む特定のEJBに対してスコープ指定ロールを作成できます。 EJBのポリシーを作成する場合、スコープ指定ロールのみがEJBにアクセス可能であると指定することができます。

2つのロールが競合している場合、スコープの狭いロールによってスコープの広いロールがオーバーライドされます。たとえば、EJBリソースに対するスコープ指定ロールは、グローバル・ロールや、そのEJBを含むエンタープライズ・アプリケーションに対するスコープ指定ロールをオーバーライドします。

セキュリティ・ロールはセキュリティ・レルム内に作成され、ロールはレルムがアクティブである場合にのみ使用できます。

詳細は、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「セキュリティ・ロールの概要」を参照してください。

グローバル・ロールの作成

セキュリティ・レルム内にデプロイされたすべてのWebLogicリソース(つまり、WebLogic Serverドメイン全体)に適用される新しいロールを作成します。

ノート

新しいグローバル・セキュリティ・ロールを作成する前に、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「デフォルトのグローバル・ロール」を確認して、既存のロールがニーズに十分かどうかを評価します。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「ロール・マッパー」、XACMLRoleMapper、「グローバル」、Rolesの順に移動します。
「新規」をクリックします。
新しいグローバル・ロールの名前を入力します。
「作成」をクリックします。

ロールの作成後、条件を使用して、どのユーザーまたはグループに含めるかを決定するポリシーを作成できます。可能な場合は常に、指定したグループのすべてのメンバーにセキュリティ・ロールを付与するグループ条件を使用することをお薦めします。

スコープ付きロールの作成

特定のリソースに適用されるポリシーでのみ使用できる新しいロールを作成します。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「ロール・マッパー」、XACMLRoleMapper、myResource、Rolesの順に移動します。

myResourceは、リソースへのノード・パスであり、複数のノードの子を含めることができます。たとえば、JMSモジュール内のキューのスコープ指定ロールを作成するには、パスは… XACMLRoleMapper、「JMSモジュール」、jmsModuleName、「キュー」、queueName、Rolesになります。
「新規」をクリックします。
新しいスコープ指定ロールの名前を入力します。
「作成」をクリックします。

セキュリティ・ポリシー

セキュリティ・ポリシーは、リソースにアクセスするためにユーザー、グループまたはロールが満たす必要がある条件を指定します。ポリシーには1つ以上の条件が必要です。条件を組み合せて複雑なポリシーを作成し、より動的なアクセス制御を実現できます。

ルート・レベルのポリシーは、特定のリソース・タイプのすべてのインスタンス(たとえば、ドメイン内のすべてのJMSリソース)に適用されます。デフォルトのセキュリティ・ポリシーはすべて、ルート・レベルのポリシーです。

特定のリソース・インスタンスにのみ適用されるポリシーを作成することもできます。インスタンスに他のリソースが含まれている場合、それに対してもこのポリシーが適用されます。たとえば、JMSシステム・リソース全体、またはそのリソース内の特定のキューまたはトピックのポリシーを作成できます。

スコープが狭いほうのポリシーが、広いほうのポリシーをオーバーライドします。たとえば、JMSシステム・リソースのセキュリティ・ポリシーとそのシステム・リソース内のJMSキューのポリシーを作成する場合、JMSキューは独自のポリシーによって保護され、システム・リソースのポリシーは無視されます。

詳細は、「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「セキュリティ・ポリシー」を参照してください。

可能な場合は、ロール条件を使用することをお薦めします。セキュリティ・ロールに基づいて条件を使用すると、複数のユーザーまたはグループを対象にして1つのセキュリティ・ポリシーを作成できるため、管理が効率的になります。

「Oracle WebLogic Serverのロールおよびポリシーを使用したリソースの保護」の「セキュリティ・ポリシー条件」を参照してください。

セキュリティ・ポリシーの構築

ポリシーを構築および編集するには、条件の引数を変更するか、ポリシー内の条件間の関係を変更します。

ノート

条件の引数のみを編集できます。条件に別の述語を使用する場合は、新しい条件を追加する必要があります。

条件には3つの異なるタイプの関係があります: AND、ORおよびCombination。

AND: AND演算子によって結合されたすべての条件を満たす必要があります。
OR: OR演算子によって結合された条件の少なくとも1つが満たされている必要があります。
Combination: 2つ以上の条件が結合され、グループとして評価される必要があります。条件「範囲内」は、組合せ自体がANDまたはOR演算子を使用して相互に関連付けられています。

デフォルトでは、新しい条件は、条件リストの最上部に単純な条件として追加されます。別の場所に新しい条件を挿入するには、既存の条件を選択し、「条件の追加」をクリックします。選択した条件の上または下に新しい条件を追加するオプションを含むドロップダウン・リストが表示されます。条件の順序は、ポリシーの解釈方法には意味がありません。

ポリシーには、複数の単純な条件または複合条件、または単純な条件と複合条件の混在を含めることができます。複合条件をネストすることもできます。

ノート

なぜ複合条件を使うのか。次のシナリオを考えてみます: リソースは、管理者が常にアクセスできるようにするが、デプロイヤ・アクセスを東部標準時の午前9時から午後5時の間に制限するために存在します。次のポリシーは、両方の要件に対処します:

条件1 (単純): Role: 管理者

OR

条件2 (複合): Role: デプロイヤANDアクセスは、09:00:00から17:00:00 GMT -5:00の間に発生

ポリシー・ページのアクションを使用して、ポリシーを編集します。

セキュリティ・ポリシーの構成に使用できるアクション。

Action	説明
条件の追加	新しい条件をポリシーに追加します。新しい条件を別の条件の上または下に追加することを選択できます。
組合せ	複数の条件を選択した場合は、条件を組み合せて複合条件を作成できます。
結合解除	複合条件を選択すると、独立(単純)条件に分解できます。
削除	ポリシーから単純条件または複合条件を削除します。ポリシーに条件がない場合、デフォルトのポリシーが適用されます。
否定	条件の意味を反転します。リソースにアクセスする基準は、元の条件とは反対になります。
リセット	ポリシーを最後の変更ではなく、最後の「保存済」変更に戻します。ポリシーを頻繁に保存するか、または「リセット」アクションを使用して意図せずに複数の変更が失われる可能性があります。

ポリシーを文字列として表す「拡張」タブからポリシーを編集することもできます。詳細タブでポリシーに加えた変更は、メインのポリシー・タブに反映され、その逆も同様です。

ポリシーを削除するには、そのすべての条件を削除します。ポリシーを削除する前に、リソース・インスタンスのデフォルトのセキュリティ・ポリシーが適切なアクセス制御を提供することを確認します。

リソース・インスタンスのポリシーの作成

特定のリソース・インスタンスにのみ適用されるセキュリティ・ポリシーを作成できます。インスタンスに他のリソースが含まれている場合、ポリシーは含まれているリソースにも適用されます。

「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「承認者」、XACMLAuthorizer、myResourceInstanceの順に移動します。

myResourceInstanceは、リソース・インスタンスへのノード・パスであり、複数のノードを含めることができます。たとえば、JMSモジュール内のキューのポリシーを作成するには、パスは"… XACMLAuthorizer、「JMSモジュール」、jmsModuleName、「キュー」、queueName"になります。
「条件の追加」をクリックします。
「述語リスト」から述語を選択します。選択した述語によっては、条件の引数を構成する必要がある場合があります。
「OK」をクリックします。
「保存」をクリックします。
ポリシーにさらに条件を追加して、複雑さを増します。

IDと信頼

WebLogic Serverは、認証局によって発行された秘密キー、デジタル証明書および信頼できる証明書を使用して、サーバーのアイデンティティとトラストを確立および検証します。

WebLogic Serverは、デフォルトのアイデンティティ・キーストアおよびデフォルトのトラスト・キーストアを提供します。これらのデフォルト・キーストアは、テストおよび開発の目的でのみ適しています。

WebLogic Server 14.1.1.0以前では、デフォルトのアイデンティティ・キーストアとデフォルトのトラスト・キーストアはそれぞれDemoIdentity.jksおよびDemoTrust.jksです。
WebLogic Server 14.1.2.0以降では、デフォルトのアイデンティティ・キーストアとデフォルトのトラスト・キーストアはそれぞれDemoIdentity.p12およびDemoTrust.p12です。

また、WebLogic Serverは、JDKのcacertsファイル内の認証局を信頼します。

詳細については、以下を参照:

「Oracle WebLogic Serverのセキュリティの理解」の「アイデンティティと信頼」
「Oracle WebLogic Serverのセキュリティの管理」の「キーストアの構成」

ノート

マルチサーバー・ドメインのデモ用証明書を使用する場合は、完全修飾DNS名を指定すると管理対象サーバー・インスタンスの起動が失敗します。この制限および推奨される回避策の詳細は、『Oracle WebLogic Serverセキュリティの管理』のCertGenの使用に関する制限に関する項を参照してください

OPSSキーストア・サービス(KSS)は、メッセージ・セキュリティのキーと証明書を管理するための代替メカニズムを提供します。 「Oracle Platform Security Servicesを使用したアプリケーションの保護」の「キーと証明書の管理」を参照してください。 OPSS KSSを使用すると、ドメイン内の全サーバーのキーおよび証明書が中央で管理および保管されるため、証明書とキーの使用が容易になります。 OPSS KSSを使用して、KSSタイプのキーストアを作成および保守できます。 Oracle Java Required Files (JRF)テンプレートがWebLogic Serverシステムにインストールされている場合は、KSSキーストアを使用するという選択肢があります。 KSSキーストアを使用するにはJRFテンプレートが必要であり、デフォルトのWebLogic Server構成では使用できません。

WebLogic Serverでのアイデンティティとトラストの構成

デジタル証明書、秘密キーおよび信頼できるCA証明書は、CertGenユーティリティ、keytoolユーティリティ、OPSSキーストア・サービス、またはインターネットで使用する証明書を作成して署名する信頼できるベンダーから取得します。 WebLogic Serverに用意されているデジタル証明書、秘密キー、および信頼性のあるCA証明書を使用することもできます。デモ用のデジタル証明書、秘密キー、および信頼性のあるCA証明書は、開発環境でのみ使用してください。

「キーストアの構成」を参照してください。
KSSを使用している場合は、KSSが正しく移入されているかどうかを確認し、必要な証明書およびキーのKSS URIおよび別名を書き留めます。キーストア、キーおよび証明書を指定する場合は、KSS URIおよびキー別名が必要になります。
秘密キー、デジタル証明書、および信頼性のあるCA証明書を格納します。秘密キーおよび信頼性のあるCA証明書はキーストアに格納されます。 KSSを使用している場合、必要なキーおよび証明書をKSSにインポートします。
WebLogic Serverインスタンスのアイデンティティ・キーストアおよびトラスト・キーストアを構成します。「キーストアの構成」を参照してください。
サーバーのSSL/TLS属性を構成します。これらの属性は、キーストア内のアイデンティティ・キーと証明書のロケーションを示します。「SSL/TLSの設定」を参照してください。

キーストアの構成

WebLogic Serverは、秘密キー、デジタル証明書および認証局により発行された信頼できる証明書を使用して、サーバーのIDと信頼を確立および検証します。アイデンティティおよび信頼には、JKSまたはPKCS12キーストアを使用できます。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「キーストアの構成」を参照してください。

ノート

「のみ」のテストおよび開発のために、WebLogic Serverはデモンストレーション・アイデンティティ・キーストアとデモンストレーション・トラスト・キーストアを提供します。本番環境では、独自のアイデンティティ・キーストアおよびトラスト・キーストアを構成する必要があります。

WebLogic Server 14.1.1.0以前では、デモ・アイデンティティ・キーストアとデモ・トラスト・キーストアはそれぞれDOMAIN_NAME/security/DemoIdentity.jksとWL_HOME/server/lib/DemoTrust.jksです。
WebLogic Server 14.1.2.0以降では、デモ・アイデンティティ・キーストアとデモ・トラスト・キーストアはそれぞれDOMAIN_NAME/security/DemoIdentity.p12とDOMAIN_NAME/security/DemoTrust.p12です。

また、JDKインストールでは、JDK/lib/security/cacerts のJKS形式のcacertsトラスト・ストアが提供されます。

カスタム・アイデンティティ・キーストアおよびカスタム・トラスト・キーストアを使用している場合:
1. 信頼できるサードパーティ認証局(CA)から秘密キーおよびデジタル証明書を入手します。
2. アイデンティティ・キーストアおよび信頼キーストアを作成します。
3. 秘密キーおよび信頼性のあるCAをキーストアにロードします。
「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
「セキュリティ」タブをクリックし、次に「キーストア」タブをクリックします。
「キーストア」ドロップダウン・リストから、秘密キー/デジタル証明書のペアおよび信頼できるCA証明書を格納および管理するタイプを選択します。
- 「デモ・アイデンティティとデモ・トラスト」 - (開発およびテストに適した)デモ証明書を使用するには、このオプションを選択します。これはデフォルト設定であり、デモンストレーションのアイデンティティ・キーストアとトラスト・キーストア、およびJDKのcacertsキーストアを使用します。
  
  デモのアイデンティティと信頼にKSSキーストアを使用するには、最初に「デモにKSSを使用」オプション(「環境: ドメイン」ページの「セキュリティ」タブの下(「拡張フィールドの表示」をクリック)で)を有効にする必要があります。これにより、デモ・アイデンティティとデモ・トラストのキー・ストアをOracle Key Store Service (KSS)から取得するかどうかが決まります。
- 「カスタム・アイデンティティとJava Standard Trust」 - 作成したアイデンティティ・キーストアと、JAVA_HOME/jre/lib/securityディレクトリのcacertsファイルに定義されている信頼できるCAを使用するには、このオプションを選択します。
- 「カスタム・アイデンティティとカスタム・トラスト」 - 作成したアイデンティティ・キーストアとトラスト・キーストアの両方を使用するには、このオプションを選択します。
- 「カスタム・アイデンティティとコマンド・ライン・トラスト」 - 作成したアイデンティティ・キーストアを使用しますが、トラスト・キーストアはWebLogic Serverを起動するコマンドで引数として渡されます。
アイデンティティ・キーストアおよびトラスト・キーストアの属性を定義します。選択したキーストア・タイプに応じて、様々なオプションを使用できます。
「保存」をクリックします。
適用可能なすべてのサーバーで繰り返します。
キーストア構成を更新していて、SSL/TLSがすでに構成されている場合は、指定した接続に従ってすべてのSSL/TLS接続が存在することを確認できます。 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。該当するサーバーを再起動します。
カスタム・キーストアを有効にし、ノード・マネージャを使用して管理対象サーバーを起動する場合は、一致するようにnodemanager.propertiesファイルも更新する必要があります。

少なくとも、環境に適用可能な次のノード・マネージャのプロパティを更新します:
- CustomIdentityAlias
- CustomIdentityKeyStoreFileName
- CustomIdentityPrivateKeyPassPhrase
- CustomIdentityKeyStorePassPhrase
- KeyStores 「Oracle WebLogic Serverのノード・マネージャの管理」の「ノード・マネージャのプロパティ」を参照してください。

証明書失効チェックの有効化

WebLogic ServerのJSSE実装では、SSL/TLS証明書バリデーション・プロセスの一環として証明書の失効ステータスをチェックするX.509証明書失効(CR)チェックがサポートされます。 CRチェックによって、受け取った証明書が発行元の認証局によって失効されていないことが保証され、証明書の使用におけるセキュリティが向上します。デフォルトでは、CRチェックはWebLogic Serverで無効になっています。

WebLogic ServerのCRチェックの実装には、オンライン証明書ステータス・プロトコル(OCSP)および証明書失効リスト(CRL)の両方が含まれます。詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「X.509 証明書失効チェック」を参照してください。

WebLogic Serverのアイデンティティ・キーストアとトラスト・キーストアが構成されていることを確認します。「アイデンティティと信頼」を参照してください。

「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブで、「SSL証明書失効チェック」サブタブをクリックします。
「証明書失効チェックの有効化」オプションをオンにします。
「失効チェック」ドロップダウン・リストから失効チェック・メソッドを選択します。デフォルトはOCSP_THEN_CRLです。

OCSPおよびCRLタブを使用して、失効チェック・メソッドの設定をカスタマイズします。オプションの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「オンライン証明書ステータス・プロトコルの使用」または「証明書失効リストの使用」を参照してください。
失効ステータスを判定できない証明書がSSL/TLS証明書パス・バリデーションに失敗するようにする場合は、「不明な失効ステータスで失敗」オプションをオンにします。

このオプションを無効にすると、X.509証明書の失効ステータスを判別できないが、SSL/TLS証明書パス・バリデーションが成功しない場合は、証明書が受け入れられます。
「保存」をクリックします。

認証局オーバーライドを証明書失効構成に構成できます。「認証局オーバーライドの構成」を参照してください。

認証局オーバーライドの構成

認証局オーバーライドを構成すると、特定の認証局(CA)によって発行された証明書に固有のCRチェック動作を指定できます。認証局オーバーライドは、ドメイン・レベルで設定されている対応する証明書失効(CR)チェック構成よりも常に優先されます。

認証局オーバーライドを使用して、特定のCAについて、ドメイン全体のCRチェック構成設定より優先させることができます。ただし、CRLローカル・キャッシュは例外で、ドメイン全体でのみ構成されます。

まだ実行していない場合は、「証明書失効チェックの有効化」の説明に従って証明書失効チェックを有効にします。
「編集ツリー」で、「セキュリティ」、「認証局の上書き」の順に移動します。
「新規」をクリックし、新しい認証局オーバーライドの名前を入力します。
「作成」をクリックします。
「識別名」フィールドで、CAの識別名を入力します。これは、このオーバーライドを適用する証明書の完全な発行者識別名(RFC 2253で定義されています)にする必要があります。

たとえば、CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState,C=US。
「一般」タブ、OCSPタブおよびCRLタブを使用して、環境に応じて設定を変更します。属性の説明および属性を構成する場合については、次を参照してください:
- 一般的な認証局オーバーライド
- 認証局オーバーライドのOCSPプロパティの構成
- 「Oracle WebLogic Serverのセキュリティの管理」の「認証局オーバーライドでのCRLプロパティの構成」。
「保存」をクリックします。

SSL/TLS

Transport Layer Security (TLS)とその先行するSecure Sockets Layer (SSL)は、ネットワーク接続を介して接続する2つのアプリケーションが他方のアイデンティティを認証できるようにし、アプリケーション間で交換されるデータを暗号化することで、セキュアな接続を保証します。

認証を使用すると、サーバーは(場合によってはクライアントも)ネットワーク接続の相手側アプリケーションのIDを検証できます。ネットワーク経由で送信されるデータは暗号化されるので、予定されている宛先以外には解釈できません。

WebLogic Serverは、デフォルトが7002の専用リスニング・ポートでSSL/TLSをサポートします。 SSL/TLS接続を確立するために、Webブラウザは、接続URLにSSL/TLSリスニング・ポートとHTTPsプロトコル(https://myserver:7002など)を指定してWebLogic Serverに接続します。

SSL/TLSは一方向または双方向として構成できます。

一方向SSL/TLSでは、サーバーはクライアントに証明書を提示する必要がありますが、クライアントはサーバーに証明書を提示する必要はありません。
双方向SSL/TLSでは、サーバーはクライアントに証明書を提示し、クライアントはサーバーに証明書を提示します。 WebLogic Serverは、SSL/TLSハンドシェイクを完了する前に、クライアントに有効な信頼できる証明書を送信するように構成できます。

WebLogic ServerでのSSL/TLSの使用方法の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「SSLの構成」を参照してください。

ノート

TLS、SSLおよびSSL/TLSという用語は、WebLogic Serverドキュメント全体で同じ意味で使用されていますが、WebLogic Serverで通信を保護するために、現在サポートされているバージョンのTLS (SSLではなく)を使用することをお薦めします。

SSL/TLSの設定

ネットワーク接続を介して接続する複数のアプリケーション間のセキュアな通信を確立します。

WebLogic Serverのアイデンティティと信頼キーストアを構成します。「キーストアの構成」を参照してください。

「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
「セキュリティ」タブをクリックし、次にSSLサブタブをクリックします。
秘密キーの別名およびパスワードにSSL/TLS属性を設定します。
「サーバー秘密キーの別名」フィールドに、サーバーの秘密キーを格納および取得するために使用する文字列別名を定義するキーストア属性を入力します。
「サーバー秘密キー・パスフレーズ」フィールドに、サーバーの秘密キーの取得に使用されるパスフレーズを定義するキーストア属性を入力します。
「拡張フィールドの表示」をクリックします。
「ホスト名検証の無効化」オプションをオフにします。

「ホスト名検証の有効化」を参照してください。
「エクスポート・キー存続期間」フィールドで、新しいキーを生成する前に、WebLogic Serverが国内サーバーとエクスポート可能なクライアント間でエクスポート可能なキーを使用できる回数を指定します。新しいキーを生成するまでにキーを使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
「インバウンド証明書バリデーション」および「アウトバウンド証明書バリデーション」ドロップダウン・リストの両方で、バリデーション・メソッドを選択します。
- 「組込みSSLの検証のみ」- 組込みの信頼性のあるCAに基づいた検証を使用します。これはデフォルトです。
- 「組込みSSLの検証および証明書パス検証プロバイダ」- 組込みの信頼性のあるCAに基づいた検証と、追加の検証を実行する構成済みCertPathValidatorプロバイダを使用します。詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「証明書参照およびバリデーション・プロバイダの使用」を参照してください。
双方向SSL/TLSを有効にします。

デフォルトでは、WebLogic Serverは、サーバーがアイデンティティをクライアントに渡す一方向SSL/TLSを使用するように構成されています。双方向SSL/TLS接続では、クライアントはサーバーのアイデンティティを検証し、そのアイデンティティ証明書をサーバーに渡します。次に、サーバーは、SSL/TLSハンドシェイクを完了する前にクライアントのアイデンティティ証明書をバリデートします。サーバーは、双方向SSL/TLSを使用するかどうかを決定します。

双方向SSL/TLSを有効にする前に、サーバーのトラスト・キーストアに、クライアントの証明書に署名した信頼できる認証局の証明書が含まれていることを確認してください。「アイデンティティと信頼」を参照してください。
1. 「双方向SSL有効」オプションをオンにします。
2. 「クライアント証明書が強制されました」オプションを有効にするかどうかを選択します。有効にすると、クライアントは証明書を提示する必要があります。証明書が提示されない場合、SSL/TLS接続は終了します。無効にすると、証明書がクライアントによって提示されていない場合でも、SSL/TLS接続は続行されます。
また、すべての管理クライアントに2方向SSL/TLSの使用を強制することもできます。管理クライアントが、双方向SSL/TLSを必要としないチャネル上のサーバーに接続しようとすると、接続は拒否されます。
1. 「環境」の「ドメイン」で、「セキュリティ」タブをクリックし、「拡張フィールドの表示」を有効にします。
2. 「管理クライアントに2方向TLSが必要」オプションをオンにします。
「保存」をクリックします。
適用可能なすべてのサーバーで繰り返します。

ホスト名検証の有効化

ホスト名検証では、クライアントが接続するURLのホスト名が、サーバーがSSL/TLS接続の一部として返送するデジタル証明書のホスト名と一致することが保証されます。証明書内のホスト名がローカル・マシンのホスト名と一致する場合、URLでlocalhost、127.0.0.1またはローカル・マシンのデフォルトのIPアドレスが指定されていると、ホスト名検証が渡されます。

ホスト名検証は、SSL/TLSクライアント(またはSSL/TLSクライアントとして機能するWebLogic Server)がリモート・ホスト上のアプリケーション・サーバーに接続する場合に便利です。ホスト名検証は、SSL/TLSクライアントによってのみ実行されます。デフォルトでは、WebLogic Serverのホスト名検証は有効になっており、本番環境では有効にしておくことをお薦めします。

ノート

次のステップは、WebLogic ServerインスタンスがSSL/TLSクライアントとして動作している場合にのみ適用されます。スタンドアロンSSL/TLSクライアントは、コマンドライン引数またはAPIを使用してホスト名検証の使用を指定します。

「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
「セキュリティ」タブ、SSLの順にクリックします。
「拡張フィールドの表示」をクリックします。
「ホスト名検証の無効化」をオフにします。
「ホスト名検証」ドロップダウン・リストからホスト名検証を選択します。

WebLogic Server 14.1.1.0.0の時点では、デフォルトの検証機能はワイルドカード検証です。
カスタム検証を使用する場合は、次のステップに従います。

ノート

カスタム・ホスト名検証を記述する場合、ホスト名検証を実装するクラスは、WebLogic ServerのCLASSPATH (SSL/TLSクライアントとして機能する場合)またはスタンドアロンSSL/TLSクライアントで指定する必要があります。

スタンドアロンSSL/TLSクライアントを使用する場合、次の引数またはAPIを使用して、コマンドラインでカスタム・ホスト名検証を指定する必要があります: -Dweblogic.security.SSL.HostnameVerifier=classname。ここで、classnameは、weblogic.security.SSL.HostnameVerifierインタフェースの実装を指定します。
1. 「WebLogicセキュリティ・サービスを使用したアプリケーションの開発」の「カスタム・ホスト名検証の使用」の説明に従って、カスタム・ホスト名検証を作成します。
2. 「ホスト名検証」ドロップダウン・リストから、「カスタム検証」を選択します。
3. 「カスタム・ホスト名検証」フィールドに、weblogic.security.SSL.HostnameVerifierインタフェースの実装の名前を入力します。
「保存」をクリックします。

すべてのサーバーSSL/TLS属性は動的です。 WebLogic Remote Consoleを使用して変更すると、対応するSSL/TLSサーバーまたはチャネルSSL/TLSサーバーが再起動し、新しい接続に新しい設定が使用されます。古い接続は引き続き古い構成で実行されます。

SSL/TLSの再起動

すべてのサーバーSSL/TLS属性は動的です。これらの属性を変更してから、WebLogic Serverを再起動せずに変更を適用できます。かわりに、対応するSSL/TLSサーバーまたはチャネルSSL/TLSサーバーのみが再起動され、新しい接続に新しい設定が使用されます。既存の接続は、古い構成で引き続き実行されます。

まだ実行していない場合は、デフォルトのセキュリティ・レルムでレルムの自動再起動をオンにします。「レルムの自動再起動の有効化」を参照してください。

レルムの自動再起動が有効になっていない場合、古い接続は引き続き古い構成で実行され、SSL/TLSの再起動後にWebLogic Serverを再起動して、指定された構成に従ってすべてのSSL/TLS接続が存在することを確認する必要があります。
「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動します。
SSL/TLSを再起動する各サーバーのチェックボックスを選択します。
「SSLの再起動」をクリックしてSSL/TLSリスニング・ソケットを再起動し、キーストアに変更を適用します。

暗号スイートの指定

WebLogic Serverでサポートされている暗号化方式群を構成します。

「編集ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
「セキュリティ」タブをクリックし、次にSSLサブタブをクリックします。
「拡張フィールドの表示」をクリックします。
「暗号スイート」フィールドに、このサーバーでサポートする暗号スイートを入力します。
「除外された暗号スイート」フィールドに、このサーバーでブロックする暗号スイートを入力します。
「保存」をクリックします。
必要に応じて、他のサーバーについても繰り返します。

クロス・ドメイン・セキュリティの有効化

クロス・ドメイン・セキュリティは、資格証明マッパーを使用してWebLogic Serverドメイン間の通信を構成することにより、2つのWebLogic Serverドメイン間のトラストを確立します。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「クロスドメイン・セキュリティの構成」を参照してください。

「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブで、「クロス・ドメイン・セキュリティ有効」をオンにします。

パフォーマンスへの影響を減らすために、WebLogic Serverは認証済サブジェクトをキャッシュします。環境のキャッシュ設定を変更する場合は、「拡張フィールドの表示」をクリックし、次の設定を変更します:
- キャッシュを無効にするには、「クロス・ドメイン・セキュリティ・キャッシュ有効」をオフにします。
- キャッシュがクリアされる頻度を変更するには、「クロス・ドメイン・セキュリティ・キャッシュTTL」値を(秒単位で)更新します。
「保存」をクリックし、変更をコミットします。
クロス・ドメイン・セキュリティのユーザーを作成し、CrossDomainConnectorsグループに割り当てます。「ユーザーの作成」を参照してください。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「クロスドメイン・ユーザーの構成」を参照してください。
クロスドメイン・セキュリティ・ユーザー用のクロスドメイン・セキュリティ資格証明マッピングを構成します。

資格証明マッピングの詳細は、「資格証明マッピング・プロバイダの構成」を参照してください。
1. 「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、myCredentialMapper、「リモート・リソース」の順に移動します。
2. 「新規」をクリックします。
3. 「クロスドメイン・プロトコルを使用」オプションをオンにします。
4. 「リモート・ドメイン」フィールドに、ローカル・ドメインと対話する必要があるリモート・ドメインの名前を入力します。
5. 「リモート・ユーザー」フィールドに、ローカル・ドメインとの対話を認可されているリモート・ドメインに構成されているユーザーのユーザー名を入力します。
6. 「リモート・パスワード」フィールドに、ローカル・ドメインとの対話を認可されているリモート・ドメインに構成されているユーザーのパスワードを入力します。
7. 「作成」をクリックします。

ドメイン間のグローバル・トラストの有効化

複数のWebLogic Serverドメインを相互運用する場合は、各ドメインに同じドメイン資格証明を指定できます。通常、ドメイン資格証明はデフォルトでランダムに生成されるため、2つのドメインが同じドメイン資格証明を持つことはありません。

この機能を有効にすると、2番目のドメインで認証を必要とせずに、RMI接続を介してWebLogic Serverドメイン間でアイデンティティが渡されます。ドメイン間の信頼関係が有効である場合、トランザクションは複数のドメインにまたがってコミットできます。信頼関係は、あるドメインのドメイン資格証明が別のドメインのドメイン資格証明と一致したときに確立されます。詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「グローバル・トラストの有効化」を参照してください。

ドメイン間のグローバル・トラストを有効にするかわりに、「クロス・ドメイン・セキュリティの有効化」で説明されているように、CrossDomainConnectorロールの使用を検討してください。

「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブで、「拡張フィールドの表示」をクリックします。
「セキュリティ資格証明」フィールドに、ドメインの新しいパスワードを入力します。強力なパスワードを選択します。
「保存」をクリックします。
グローバル・トラストを有効にする各ドメインで同じ手順を実行し、まったく同じパスワードを入力します。

接続フィルタリングの構成

接続フィルタを使用すると、ネットワーク・レベルでアクセスを拒否できます。接続フィルタは、個々のサーバー、サーバー・クラスタ、または内部ネットワーク(イントラネット)にあるサーバー・リソースの保護に使用できます。

接続フィルタの詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「接続フィルタの使用」を参照してください。

「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
「セキュリティ」タブで、「フィルタ」サブタブを選択します。
受け入れられたメッセージのロギングを有効にするには、「接続ロガー有効」オプションをオンにします。接続ロガーは、成功した接続と接続データをサーバーにログします。この情報は、サーバーの接続に関連する問題をデバッグするために使用できます。
「接続フィルタ」フィールドで、ドメインで使用する接続フィルタ・クラスを指定します。
- デフォルトの接続フィルタを構成するには、weblogic.security.net.ConnectionFilterImplと指定します。
- カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、WebLogic Serverのクラス・パスにも存在する必要があります。
「接続フィルタ・ルール」フィールドに、接続フィルタ・ルールの構文を入力します。

接続フィルタ・ルールの詳細は、「WebLogicセキュリティ・サービスを使用したアプリケーションの開発」の「接続フィルタ・ルールの記述に関するガイドライン」を参照してください。
サーバーの起動時にフィルタ・ルールのエラーをWebLogic Serverで無視する場合は、「接続フィルタでルール・エラーを無視」オプションをオンにします。
「保存」をクリックします。

JEP 290フィルタリングの許可リストの作成

セキュリティを高めるために、WebLogic Serverは、JDK JEP 290メカニズムを使用して受信したシリアライズJavaオブジェクトをフィルタして、デシリアライズできるクラスを制限します。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「Oracle WebLogic ServerでのJEP 290の使用」を参照してください。

許可リスト・モデルを使用する場合、WebLogic Serverおよび顧客は、直列化復元を許可される受入れ可能なクラスおよびパッケージのリストを定義し、他のすべてのクラスをブロックします。

ノート

WebLogic Serverでは、JEP 290フィルタリングでのブロック・リストの使用もサポートされています。ブロック・リストの使用方法は、「Oracle WebLogic Serverのセキュリティの管理」の「WebLogic ServerでのJEP 290ブロック・リストおよび許可リストの使用方法」を参照してください。

WebLogic Serverと顧客アプリケーションのデシリアライズの両方で使用されるすべてのクラスおよびパッケージを記録するようにドメインを構成します。
1. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
2. 「セキュリティ」タブで、「リストの許可」サブタブを選択します。
3. 「記録使用可能」オプションをオンにします。
  
  記録が有効な場合、ブロックリストに指定されているクラスを除くすべてのクラスが、デシリアライゼーション中に許可されます。
4. 変更を保存してコミットします。
記録された許可リスト構成ファイルによって、アプリケーションが正常に実行されるために許可する必要があるすべてのパッケージおよびクラスを適切にカバーしていることを確認するために、テストの完全なセットを実行します。デシリアライズが発生すると、各クラスがDOMAIN_HOME/config/security/jep290-recorded.serial.propertiesに記録されます。

次に、サンプルのjep290-recorded.serial.propertiesを示します:
```
Wed May 19 23:55:13 UTC 2021
weblogic.oif.serialFilter=        com.company1.common.collections.objs.*;        com.company1.common.tools.Calculator;        com.company2.shared.tools.Converter
weblogic.oif.serialGlobalFilter=        com.company1.common.lists.AList;        com.company1.common.tools.Calculator;        com.company2.shared.tools.*
```
「記録使用可能」オプションをオフにします。変更を保存してコミットします。
許可リストを使用するようにドメインを構成します。
1. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。 「セキュリティ」タブをクリックし、次に「リストの許可」サブタブをクリックします。 「違反アクション」ドロップダウン・リストから、適切な設定を選択します。
  - IGNORE - 許可リストを無視し、ブロック・リストを使用します。デシリアライズ中に見つかったクラスがブロックリストに存在する場合、そのクラスのデシリアライズはブロックされます。
  - LOG - 違反が発生した場合にメッセージをログに記録しますが、ブロック・リストに表示されないかぎり、クラスを許可します。
  - DENY - 許可リストで指定されたクラスを除くすべてのものをブロックし、クラスがブロックされたときにメッセージをログに記録します。
  ノート
  ネットワーク・アクセス・ポイントを使用して、チャネルでAllowListViolationActionを設定することもできます。これにより、信頼性のない外部チャネルでは許可リストを、内部の信頼性のあるチャネルではブロックリストを使用できます。
2. 「保存」をクリックし、変更をコミットします。
デフォルトでは、許可リスト構成ファイルを含むディレクトリは60秒ごとにポーリングされます。デフォルトのポーリング間隔を変更する場合は、次の手順を実行します:
1. 「編集ツリー」で、「環境」、「ドメイン」の順に移動します。
2. 「セキュリティ」タブをクリックし、次に「リストの許可」サブタブをクリックします。
3. 「シリアル・プロファイル・ポーリング間隔」フィールドに、新しい間隔を入力します。
4. 「保存」をクリックします。
作成した許可リスト構成ファイルを本番ドメインのDOMAIN_HOME/config/securityディレクトリにコピーして、許可リストを使用するように本番ドメインを構成します。

ノート
Oracleでは、AllowListViolationActionをLogに設定して本番ドメインを一定期間実行し、すべてのクラスおよびパッケージが記録されるようにすることをお薦めします。

許可リスト構成ファイルの正確性を維持することが重要です。新しいアプリケーションがドメインにデプロイされるか、新しいバージョンのアプリケーションがデプロイされるたびに、このプロセス全体を繰り返し、許可リストを再作成するか、新しいアプリケーションで許可リストを検証して、新規または更新されたアプリケーションに必要なすべてのパッケージおよびクラスが許可リストに含まれていることを確認する必要があります。

SAML 2.0サービスの構成: 主なステップ

WebLogic Serverインスタンスは、サービス・プロバイダまたはアイデンティティ・プロバイダとして構成できます。

WebLogic ServerでSAML 2.0を使用する方法の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0サービスの構成」を参照してください。

ノート

WebLogic Remote Consoleを使用してSAML 1.1サービスを構成することはできません。

ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを実行する場合は、RDBMSセキュリティ・ストアが構成されているドメインを作成します。「RDBMSセキュリティ・ストアの使用」を参照してください。

RDBMSセキュリティ・ストアは、管理するデータを、そのデータを共有するすべてのWebLogic Serverインスタンス間で同期できるように、本番環境のSAML 2.0セキュリティ・プロバイダで必要です。

Oracleでは、RDBMSセキュリティ・ストアを使用するように既存のドメインをアップグレードすることはお薦めしません。 RDBMSセキュリティ・ストアを使用する場合は、ドメインの作成時にRDBMSセキュリティ・ストアを構成する必要があります。 RDBMSセキュリティ・ストアを使用する既存のドメインがある場合は、新しいドメインを作成し、既存のセキュリティ・レルムを移行します。

「Oracle WebLogic Serverのセキュリティの管理」の「RDBMSセキュリティ・ストアの管理」を参照してください。
「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0のWebアプリケーション・デプロイメントに関する考慮事項」で説明されている考慮事項を確認してください。
SAML 2.0の全般的なサービスの構成各サーバー・インスタンスに同じ構成設定を適用します。「SAML 2.0一般サービスの構成」を参照してください。
SAML 2.0アイデンティティ・プロバイダ・サイトを構成する場合、
1. セキュリティ・レルムにSAML 2.0資格証明マッピング・プロバイダのインスタンスを作成します。「資格証明マッピング・プロバイダの構成」を参照してください。
2. SAML 2.0アイデンティティ・プロバイダ・サービスの構成各サーバー・インスタンスに同じ構成設定を適用します。「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」を参照してください。
3. サイトについて記述したメタデータ・ファイルを公開し、サービス・プロバイダ・パートナに手動で配布します。「SAMLメタデータの公開」を参照してください。
4. サービス・プロバイダ・パートナを作成して構成します。「SAML 2.0 Webサービス・プロバイダ・パートナの作成」または「SAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成」を参照してください。
SAML 2.0サービス・プロバイダ・サイトを構成する場合、
1. セキュリティ・レルムにSAML 2.0アイデンティティ・アサーション・プロバイダのインスタンスを作成します。「認証プロバイダまたはアイデンティティ・アサーション・プロバイダの構成」を参照
2. 仮想ユーザーにSAMLを使用したログインを許可する場合は、SAML認証プロバイダのインスタンスを作成します。 「Oracle WebLogic Serverのセキュリティの管理」の「SAML認証プロバイダの構成」を参照してください。
3. SAML 2.0サービス・プロバイダ・サービスの構成各サーバー・インスタンスに同じ構成設定を適用します。「SAML 2.0サービス・プロバイダ・サービスの構成」を参照
4. サイトについて記述したメタデータ・ファイルを公開し、IDプロバイダ・パートナに手動で配布します。「SAMLメタデータの公開」を参照
5. IDプロバイダ・パートナを作成して構成します。「SAML 2.0 Webサービス・アイデンティティ・プロバイダ・パートナの作成」または「SAML 2.0 Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成」を参照してください。

SAML 2.0全般サービスの構成

WebLogic ServerインスタンスをSAML 2.0アイデンティティ・プロバイダとして構成するか、SAML 2.0サービス・プロバイダとして構成するかに関係なく、サーバーの一般的なSAML 2.0サービスを構成する必要があります。

詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0一般サービスの構成」を参照してください。

「SAML 2.0サービスの構成: 主なステップ」の説明に従って、SAML 2.0サービスを構成する一般的なステップを確認します。
「編集ツリー」で、「環境」、「サーバー」の順に移動します。
SAML一般サービスを構成するサーバー・インスタンスを選択します。
「セキュリティ」タブをクリックし、次に「SAML 2.0一般」サブタブをクリックします。
SAML 2.0アーティファクトの格納に永続キャッシュを使用するには、「レプリケートされたキャッシュ」オプションを有効にします。

このオプションは、ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを構成する場合に必要となります。クラスタでSAML 2.0サービスを構成する場合は、各管理対象サーバー・インスタンスでこのオプションを個別に有効にする必要があります。
環境の必要に応じて設定を変更します。フィールドの説明および構成が必要な場合については、「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0一般サービスについて」を参照してください。
「保存」をクリックします。
ドメイン内の残りのサーバーについて繰り返します。すべてのサーバーにまったく同じ構成設定を適用してください。
メタデータ・ファイルを公開します。「SAMLメタデータの公開」を参照してください。

次に、サーバーをアイデンティティ・プロバイダとして、またはサービス・プロバイダとして構成します。それぞれ「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」または「SAML 2.0サービス・プロバイダ・サービスの構成」を参照してください。

SAMLメタデータの公開

SAMLメタデータ・ファイルには、このサイトのSAML 2.0サービスに関する情報が含まれます。このファイルをフェデレーテッド・パートナと共有して、SAML 2.0 webシングル・サインオンを容易にします。

「モニタリング・ツリー」で、「環境」、「サーバー」、myServerの順に移動します。
SAML 2.0タブで、「メタデータの公開」をクリックします。
「メタデータの公開」ダイアログ・ボックスで、メタデータ・ファイルを保存するファイル・パスのロケーションを指定します。ファイル・パスは管理サーバーからの相対パスである必要があります。
「完了」をクリックします。
メタデータ・ファイルをフェデレーテッド・パートナに配布します。配布の推奨事項については、「Oracle WebLogic Serverのセキュリティの管理」の「メタデータ・ファイルの公開および配布」を参照してください。

SAML 2.0 IDプロバイダ・サービスの構成

SAML 2.0アイデンティティ・プロバイダは、プリンシパルのアイデンティティ情報を作成、維持、管理したり、フェデレーション内の他のサービス・プロバイダ・パートナのSAML 2.0アサーションを生成して、そのようなパートナにプリンシパルの認証を提供します。

「SAML 2.0一般サービスの構成」の説明に従って、SAML 2.0一般サービス構成を実行します。
SAML 2.0資格証明マッピング・プロバイダをまだ構成していない場合、構成します。「資格証明マッピング・プロバイダの構成」を参照してください。
「編集ツリー」で、「環境」、「サーバー」の順に移動します。
アイデンティティ・プロバイダのロールでサーバーのSAML構成を実行するサーバー・インスタンスを選択します。
「セキュリティ」タブをクリックし、次に「SAML 2.0アイデンティティ・プロバイダ」サブタブをクリックします。
「有効」オプションを有効にして、アイデンティティ・プロバイダのロールでこのサーバーのSAML 2.0サービスをアクティブ化します。
環境の必要に応じて設定を変更します。属性の説明および属性を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0アイデンティティ・プロバイダ・サービスの構成」を参照してください。
「保存」をクリックします。
残りのサーバーについても繰り返します。すべてのサーバーに同じ構成設定を適用してください。

サービス・プロバイダ・パートナを作成して構成します。「SAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成」または「SAML 2.0 Webサービス・プロバイダ・パートナの作成」を参照してください。

フェデレーション・パートナと調整し、このSAMLオーソリティに対して有効化したSAMLバインディングと、署名ドキュメントの要件がパートナと互換性を持つようにします。

SAML 2.0 Webサービス・プロバイダ・パートナの作成

SAML 2.0サービス・プロバイダ・パートナは、IDプロバイダ・サイトによって生成されたSAML 2.0アサーションを消費するエンティティです。

信頼できるセキュアなメカニズムを使用して、パートナ、バインディング・サポート、証明書およびキーなどを説明するメタデータ・ファイルをフェデレーテッド・パートナから取得します。 「Oracle WebLogic Serverのセキュリティの管理」の「サービス・プロバイダ・パートナのメタデータ・ファイルの取得」を参照してください。
「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」の順に移動し、サーバー用に構成したSAML 2.0資格証明マッピング・プロバイダを選択します。
「パートナ」ノードをクリックします。
「新規」をクリックします。
サービス・プロバイダ・パートナの名前を入力します。
「タイプ」ドロップダウン・リストから、「Webサービス・パートナ」を選択します。
「作成」をクリックします。
「有効」オプションを有効にして、このサーバーとこのサービス・プロバイダ・パートナ間の相互作用を有効にします。
環境の必要に応じて設定を変更します。設定の説明および設定を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「Webシングル・サインオン・サービス・プロバイダ・パートナの作成と構成」を参照してください。
「保存」をクリックします。

SAML 2.0 Webシングル・サインオン・サービス・プロバイダ・パートナの作成

SAML 2.0サービス・プロバイダ・パートナは、IDプロバイダ・サイトによって生成されたSAML 2.0アサーションを消費するエンティティです。

信頼できるセキュアなメカニズムを使用して、パートナ、バインディング・サポート、証明書およびキーなどを説明するメタデータ・ファイルをフェデレーテッド・パートナから取得します。 「Oracle WebLogic Serverのセキュリティの管理」の「サービス・プロバイダ・パートナのメタデータ・ファイルの取得」を参照してください。
「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」の順に移動し、サーバー用に構成したSAML 2.0資格証明マッピング・プロバイダを選択します。
「パートナ」ノードをクリックします。
「新規」をクリックします。
サービス・プロバイダ・パートナの名前を入力します。
「タイプ」ドロップダウン・リストから、「Webシングル・サインオン・サービス・パートナ」を選択します。
「メタデータ・ファイル名」フィールドに、フェデレーテッド・パートナから受信したメタデータ・パートナ・ファイルへのファイル・パスを入力します。
「作成」をクリックします。
「有効」オプションを有効にして、このサーバーとこのサービス・プロバイダ・パートナ間の相互作用を有効にします。
環境の必要に応じて設定を変更します。設定の説明および設定を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「Webシングル・サインオン・サービス・プロバイダ・パートナの作成と構成」を参照してください。
「保存」をクリックします。

SAML 2.0サービス・プロバイダ・サービスの構成

サービス・プロバイダは、SAMLアサーションを受け取り、それらのアサーションからアイデンティティ情報を抽出することができるSAMLオーソリティです。抽出されたアイデンティティ情報は、ローカルのサブジェクトや必要に応じてグループにマップされ、これらが認証可能になります。

「SAML 2.0一般サービスの構成」の説明に従って、SAML 2.0一般サービス構成を実行します。
まだ行っていない場合は、SAML 2.0アイデンティティ・アサーション・プロバイダを構成します。「認証プロバイダまたはアイデンティティ・アサーション・プロバイダの構成」を参照してください。
「編集ツリー」で、「環境」、「サーバー」の順に移動します。
SAML構成を実行するサーバー・インスタンスを選択します。
「セキュリティ」タブをクリックし、次に「SAML 2.0サービス・プロバイダ」サブタブをクリックします。
「有効」オプションを有効にして、サービス・プロバイダのロールでこのサーバーのSAML 2.0サービスをアクティブ化します。
環境の必要に応じて設定を変更します。属性の説明および属性を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「SAML 2.0サービス・プロバイダ・サービスの構成」を参照してください。
「保存」をクリックします。
残りのサーバーについても繰り返します。すべてのサーバーに同じ構成設定を適用してください。

IDプロバイダ・パートナを作成して構成します。「SAML 2.0 Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成」または「SAML 2.0 Webサービス・アイデンティティ・プロバイダ・パートナの作成」を参照してください。

SAML 2.0 Webサービス・アイデンティティ・プロバイダ・パートナの作成

SAML 2.0 IDプロバイダ・パートナは、サービス・プロバイダ・サイトによって消費されるSAML 2.0アサーションを生成するエンティティです。

信頼できるセキュアなメカニズムを使用して、パートナ、バインディング・サポート、証明書およびキーなどを説明するメタデータ・ファイルをフェデレーテッド・パートナから取得します。 「Oracle WebLogic Serverのセキュリティの管理」の「アイデンティティ・プロバイダ・パートナのメタデータ・ファイルの取得」を参照してください。
「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」の順に移動し、構成したSAML 2.0アイデンティティ・アサーション・プロバイダを選択します。
「パートナ」ノードをクリックします。
「新規」をクリックします。
アイデンティティ・プロバイダ・パートナの名前を入力します。
「タイプ」ドロップダウン・リストから、「Webサービス・アイデンティティ・パートナ」を選択します。
「作成」をクリックします。
「有効」オプションを有効にして、このサーバーとこのアイデンティティ・プロバイダ・パートナ間の相互作用を有効にします。
環境の必要に応じて設定を変更します。設定の説明および設定を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成と構成」を参照してください。
「保存」をクリックします。
「アサーション署名証明書」タブをクリックして、アイデンティティ・プロバイダ・パートナのアサーション署名証明書を構成します。
1. パートナと協力して、アサーション署名証明書を安全な方法で取得します。詳細は、「Oracle WebLogic ServerのWebLogic Webサービスの保護」の「アイデンティティ用のSecurity Assertion Markup Language (SAML)トークンの使用」を参照してください。
2. 「ファイルから証明書をインポート」をクリックし、X.509証明書を含む.pemまたは.derファイルへのファイル・パスを入力します。
3. 「完了」をクリックします。
  
  WebLogic Remote Consoleは、インポートされた証明書から取得された情報をページに移入します。

SAML 2.0 Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成

SAML 2.0 IDプロバイダ・パートナは、サービス・プロバイダ・サイトによって消費されるSAML 2.0アサーションを生成するエンティティです。

信頼できるセキュアなメカニズムを使用して、パートナ、バインディング・サポート、証明書およびキーなどを説明するメタデータ・ファイルをフェデレーテッド・パートナから取得します。 「Oracle WebLogic Serverのセキュリティの管理」の「アイデンティティ・プロバイダ・パートナのメタデータ・ファイルの取得」を参照してください。
「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「認証プロバイダ」の順に移動し、サーバー用に構成したSAML 2.0アイデンティティ・アサーション・プロバイダを選択します。
「パートナ」ノードをクリックします。
「新規」をクリックします。
アイデンティティ・プロバイダ・パートナの名前を入力します。
「タイプ」ドロップダウン・リストから、「Webシングル・サインオン・アイデンティティ・パートナ」を選択します。
「メタデータ・ファイル名」フィールドに、フェデレーテッド・パートナから受信したメタデータ・パートナ・ファイルへのファイル・パスを入力します。
「作成」をクリックします。
環境の必要に応じて設定を変更します。設定の説明および設定を構成する場合については、「Oracle WebLogic Serverのセキュリティの管理」の「Webシングル・サインオン・アイデンティティ・プロバイダ・パートナの作成と構成」を参照してください。
「保存」をクリックします。

RDBMSセキュリティ・ストアの使用

外部RDBMSは、認可、ロール・マッピング、資格証明マッピングおよび証明書レジストリ・プロバイダのデータ・ストアとして使用できます。ドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを使用する場合は、RDBMSセキュリティ・ストアと呼ばれるこのデータ・ストアを強くお薦めします。

RDBMSセキュリティ・ストアを使用する予定の場合は、最初にドメインを作成するときに設定する必要があります。既存のドメインがある場合は、新しいドメインを作成し、RDBMS用に構成してから、既存のドメインから新しいドメインにセキュリティ・データを移行する必要があります。既存のドメインでRDBMSセキュリティ・ストアを有効にすることはお薦めしません。

WebLogic ServerでのRDBMSセキュリティ・ストアの使用方法の詳細は、「Oracle WebLogic Serverのセキュリティの管理」の「RDBMSセキュリティ・ストアの管理」を参照してください。

RDBMSの影響を受けるセキュリティ・プロバイダのリストは、「Oracle WebLogic Serverのセキュリティの管理」の「RDBMSセキュリティ・ストアを使用するセキュリティ・プロバイダ」を参照してください。

RDBMSセキュリティ・ストアとして使用する上でこのリリースのWebLogic Serverでサポートされている具体的なRDBMSシステムのリストについては、Oracle Fusion Middlewareでサポートされるシステム構成を参照してください。

ドメイン構成ウィザードまたはWLSTオフラインを使用して、新しいWebLogicドメインを作成します。 「構成ウィザードを使用したWebLogicドメインの作成」の「WebLogicドメインの作成」または「WebLogic Scripting Toolの理解」の「WLSTオフラインを使用したWebLogicドメインの作成」をそれぞれ参照してください。

ノート
この時点ではドメインを起動しないでください。
WLSTオフラインを使用して、RDBMSセキュリティ・ストアを有効にします。 「Oracle WebLogic Serverのセキュリティの管理」の「WLSTオフラインを使用したRDBMSセキュリティ・ストアの作成」を参照してください。
データ・ストアにRDBMS表を作成します。 WebLogic Serverのインストール・ディレクトリには、サポートされている各RDBMSシステム用のスクリプト・セットが格納されています。

通常、このステップはデータベース管理者が実行します。スクリプトの説明、製品インストール・ディレクトリでのスクリプトのロケーション、およびスクリプトの実行手順については、「Oracle WebLogic Serverのセキュリティの管理」の「セキュリティ・データストアでのRDBMS表の作成」を参照してください。
ドメインを起動します。

RDBMSセキュリティ・ストアの構成

RDBMSセキュリティ・ストアの設定を更新できます。ただし、RDBMSセキュリティ・ストアのデータベース設定は、作成後に変更しないでください。

「編集ツリー」で、「セキュリティ」、「レルム」、myRealm、「RDBMSセキュリティ・ストア」の順に移動します。
「新規」をクリックします。
「名前」、「接続URL」、「ドライバ名」および「ユーザー名」の各フィールドに値を入力します。

データベース名、タイプおよびユーザー資格証明は、ドメインの作成時に設定した値と一致する必要があります。
「作成」をクリックします。
RDBMSセキュリティ・ストアでデータベース情報をメモリーに正しくキャッシュできるように、JNDIおよびJMSの適切な設定を指定します。 RDBMSが複数のJVMで実行されている場合(たとえば、ドメインに複数のサーバーがある場合や、他のOracle製品が新しいドメインと同じRDBMSストアを共有している場合)、セキュリティ・データの整合性を確保するためにこれらのキャッシュを同期する必要があります。サーバーの同期を構成するには:
1. JNDIのユーザー名とパスワードを指定します。ここでは、JNDIへのアクセス権を持つ、セキュリティ・レルム内の有効なユーザーを指定できます。
2. JMSトピックを作成します。既存のものを再利用できます。「JMSシステム・モジュールのリソースの構成」を参照してください。
  
  ノート
  RDBMSセキュリティ・ストアが構成されているマルチサーバー・ドメインでJMSアクションを構成しないと、セキュリティの脆弱性が生じる可能性があります。
「保存」をクリックします。

RDBMSセキュリティ・ストアが構成されているJMSトピックが停止した場合は、そのリストアに関する重要な情報について、「Oracle WebLogic Serverのセキュリティの管理」の「RDBMSセキュリティ・ストアの管理」を参照してください。