| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理 12c (12.2.1.3.0) E90347-06 |
|
 前 |
 次 |
WebLogic Serverセキュリティの管理タスクは、主に1つ以上のセキュリティ・レルムの作成および構成に的を絞っています。各セキュリティ・レルムで、一連のセキュリティ・プロバイダの構成、保護が必要なWebLogicリソースのセキュリティ・ポリシーの作成、ユーザー・アカウント保護のための構成オプションの選択、アイデンティティおよび信頼の構成を実行します。
この章には次のトピックが含まれます:
セキュリティ管理の概念をより広く概観するには、Oracle WebLogic Serverセキュリティの理解を参照してください。
ノート:
このドキュメントでは、6.xという用語はWebLogic Server 6.0、6.1、およびそれらに関連付けられたサービス・パックを表します。
WebLogic Serverには、デフォルトのセキュリティ・レルムmyrealmがあり、WebLogicの裁決、認証、IDアサーション、認可、ロール・マッピング、および資格証明マッピングの各プロバイダがデフォルトで構成されています。
新しいセキュリティ・レルムを構成して認証機能と認可機能をカスタマイズし、必要なセキュリティ・サービスを用意します。次に、その新しいセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定します。
WebLogic Serverのデフォルト・セキュリティ構成については、「WebLogic Serverのデフォルト・セキュリティ構成」を参照してください。
セキュリティ・レルムを構成してデフォルト・セキュリティ・レルムに設定する方法については、デフォルト・セキュリティ構成のカスタマイズを参照してください。
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セキュリティ・プロバイダの開発』を参照してください。
セキュリティ・ポリシーの作成は、多数のオプションがある複数のステップからなるプロセスです。このプロセスについて理解を深めるには、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を読んでください。WebLogic Serverのデプロイメントに対するセキュリティを完全に構成するには、そのドキュメントをWebLogicセキュリティの保護とあわせて使用する必要があります。
この項には次のトピックが含まれます:
WebLogicリソースは、権限のないアクセスから保護することができる基底のWebLogic Serverエンティティを表す構造化オブジェクトです。WebLogic Serverでは、以下のリソースが定義されます。
WebLogic Server管理コンソールや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 Serverでは、セキュリティ・ロールおよびポリシーの構成モデルを選択できます。標準のJava Enterprise Editionモデルでは、ロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。WebLogicセキュリティ・サービスは、デプロイメント記述子に定義された情報を使用してWebアプリケーションまたはEJBのためにセキュリティ・ロールを付与し、セキュリティ・プロファイルを定義することができます。WebLogic Serverを最初に起動するときに、web.xml、weblogic.xml、ejb-jar.xml、またはweblogic-ejb-jar.xmlデプロイメント記述子に格納されたセキュリティ・ロールとセキュリティ・ポリシーの情報が、デフォルト・セキュリティ・レルムに構成されている認可プロバイダとロール・マッピング・プロバイダにロードされます。ロールやポリシーの情報は、後からWebLogic Server管理コンソールで確認できます。(必要に応じ、別のセキュリティ・モデルを使用するようにセキュリティ・レルムを構成して、WebLogic Server管理コンソールからこれらの情報を変更できるようにすることも可能です。)
デプロイメント記述子内の情報を利用するには、セキュリティ・レルム内の少なくとも1つの認可プロバイダとロール・マッピング・プロバイダがそれぞれDeployableAuthorizationProviderおよびDeployableRoleProviderセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装している必要があります。このSSPIを使用すると、プロバイダはデプロイメント記述子から情報を(検索ではなく)格納できます。デフォルトでは、WebLogic認可プロバイダとロール・マッピング・プロバイダがこのSSPIを実装しています。
WebLogic Server管理コンソールでデプロイメント記述子内のセキュリティ・ロールとセキュリティ・ポリシーを変更し、それ以降もこの情報をWebLogic Server管理コンソールから変更する予定がある場合は、管理コンソールで行った変更がWebLogic Serverの再起動時にデプロイメント記述子の古い情報で上書きされないように、セキュリティ・レルムに構成オプションを設定できます。
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のWebアプリケーションおよびEJBリソースの保護のオプションに関する項を参照してください。
myrealmがデフォルト・セキュリティ・レルムとして設定され、WebLogic裁決、認証、アイデンティティ・アサーション、XACML認可、資格証明マッピング、XACMLロール・マッピング、および証明書パスの各プロバイダがセキュリティ・プロバイダとしてそのレルムに定義されています。WebLogic Serverの組込みLDAPサーバーは、これらのデフォルト・セキュリティ・プロバイダ用のデータ・ストアとして使用されます。デフォルト・セキュリティ構成を使用するには、セキュリティ・レルムでユーザー、グループ、およびセキュリティ・ロールを定義し、セキュリティ・ポリシーを作成してドメイン内のWebLogicリソースを保護する必要があります。ノート:
WebLogic Serverには、WebLogic認可プロバイダとWebLogicロール・マッピング・プロバイダがあります。これらのプロバイダは、WebLogic Server管理コンソールなどではそれぞれ「デフォルト認可プロバイダ」、「デフォルト・ロール・マッピング・プロバイダ」と呼ばれています。WebLogic Server 9.1から、新しく作成されるセキュリティ・レルムでは、これらのプロバイダはデフォルトのプロバイダではなくなりました。代わりに、XACML認可プロバイダとXACMLロール・マッピング・プロバイダがデフォルトのプロバイダになっています。
WebLogicセキュリティ・プロバイダで提供される機能の詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。これらのWebLogicセキュリティ・プロバイダがセキュリティ要件を必ずしも完全に満たしていない場合には、それらを補うか、あるいは入れ替えることができます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
デフォルト・セキュリティ構成では要件が満たされない場合、WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダを自由に組み合せて新しいセキュリティ・レルムを作成し、そのセキュリティ・レルムをデフォルト・セキュリティ・レルムとして設定できます。デフォルト・セキュリティ構成のカスタマイズを参照してください。
本番環境でWebLogic Serverを使用する予定がある場合は、必ず次を実行してください。
WebLogic Serverをインストールする前にホスト環境を保護します。「WebLogic Serverのセキュア・インストールの実行」の説明に従います。
WebLogicドメインを作成するときは、「本番用のWebLogicドメインの作成」の説明に従って、ドメインが本番モードまたは保護された本番モードで実行されるように構成します。
初めてドメインを起動したらすぐに、「ドメイン作成後の保護」のタスクを実行します。
「デフォルト・セキュリティ構成をカスタマイズする理由」に目を通して、デフォルト・セキュリティ構成を使用するかどうかを決定します。
デフォルト・セキュリティ構成を使用する場合は、ステップ3に進みます。
デフォルト・セキュリティ構成を使用しない場合は、ステップ2に進みます。
デフォルト・セキュリティ・レルムで、追加のセキュリティ・プロバイダを構成するか(たとえば、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ロールおよびポリシーによるリソースの保護とOracle WebLogic Serverセキュティの管理 12cに目を通してください。
WebLogic Serverのアイデンティティおよび信頼の構成します。(このステップはオプションですが、特に本番環境の場合には強くお薦めします。)キーストアの構成を参照してください。
WebLogic Serverに対してSSLを有効にします。(このステップもオプションですが、すべての本番環境で強くお薦めします。)「SSLの設定: 主なステップ」を参照してください。
本番に移行する場合、『Oracle WebLogic Server本番環境の保護』で説明されている追加のセキュリティ・オプションを確認し、実装してください。
また、以下のことを行うことができます。
接続フィルタを構成します。「接続フィルタの使用」を参照してください。
WebLogicドメイン間の相互運用性を有効化します。クロス・ドメイン・セキュリティの構成を参照してください。
一般に、コンソールで実行できる構成タスクは、WLST、RESTまたはJMXを使用して実行することもできます。次の表に、WebLogic Server管理コンソールにかわるセキュリティ構成用ツールの使用に関する情報の参照先を示します。
| 使用するツール | 参照先 |
|---|---|
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サーバーの選択に関する項 |
セキュリティ・レルムを管理する場合は、タスクに応じて2つの異なるMBeanサーバーを使用する必要があります。
セキュリティMBean属性の値を設定する場合は、編集MBeanサーバーを使用します。
セキュリティ・プロバイダMBeanでユーザー、グループ、ロール、およびポリシーを追加したり、他の操作を呼び出したりする場合は、実行時MBeanサーバーまたはドメイン実行時MBeanサーバーを使用します。
また、両立不能な変更が発生しないように、自身のクライアントや別のJMXクライアントに現在アクティブな編集セッションがある場合にはセキュリティ・プロバイダMBeanで操作を呼び出すことはできません。WebLogic Server管理コンソールでは、この制限が自動的に適用され、適切なMBeanサーバーへのアクセスが自動的に行われます。WebLogic Server管理コンソールを使用する場合には、「ドメイン」→「セキュリティ」→「全般」ページで「動的でない変更が行われた場合にセキュリティ管理操作を許可する」を有効化することで、この制限をオーバーライドできます。この属性をtrueに設定すると、ユーザーはサーバーを再起動しなくてもセキュリティ管理操作を実行できるようになります。この属性は、新しいMBean編集セッションが開始されると、falseにリセットされます。
たとえば、DefaultAuthenticatorMBeanのMinimumPasswordLength属性の値は、ドメインの構成ドキュメントに格納されています。このドキュメントに対するすべての変更はWebLogic Serverによって制御されているため、この属性の値を変更するには、編集MBeanサーバーを使用してドメインの構成に対してロックを取得する必要があります。DefaultAuthenticatorMBeanのcreateUser操作は、LDAPサーバーにデータを追加します。この操作はWebLogic Serverによって制御されていません。DefaultAuthenticatorMBeanの構成とそれがLDAPサーバーで使用するデータの間で両立不能な変更が発生しないように、自身や別のユーザーがMinimumPasswordLength属性の変更を行っている場合にはcreateUser操作を呼び出すことはできません。さらに、この属性の変更にはWebLogic Serverの再起動が必要になるため、サーバーが再起動するまでcreateUser操作を呼び出すことができません。
ノート:
WebLogic認証プロバイダのWebサービス・パスワード・ダイジェスト機能は、ハッシュされたパスワードを使用しません。パスワード・ダイジェストを実行時に計算できるように、かわりに可逆暗号化が使用されます。(パスワード・ダイジェスト認証は、サーブレットとWebアプリケーションではサポートされていません。)「パスワード・ダイジェストの有効化」属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「デフォルト認証プロバイダ: プロバイダ固有」を参照してください。
SerializedSystemIni.datファイルにドメインのプライマリ暗号化キーが含まれます。このファイルは特定のWebLogicドメインに関連付けられるため、ドメイン間で移動することはできません。
JDBCパスワードなどの機密性の高い構成データは、プライマリ暗号化キーを使用して暗号化されます。こうして暗号化されたデータはconfig.xmlに保存されます。または、埋込みLDAPのセキュリティ・メタデータ/ポリシー・ストアに保存されます。(構成されている場合はRDBMSが使用されます。)
SerializedSystemIni.datファイルが破損した場合は、WebLogicドメインを再構成する必要があります。そのため、次の注意事項を考慮する必要があります。
SerializedSystemIni.datファイルのバックアップを作成し、安全な場所に保管します。
WebLogic Serverデプロイメントのシステム管理者が読み書き権限を持ち、その他のユーザーは何の権限も持たないように、SerializedSystemIni.datファイルに権限を設定します。
