| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 11gリリース1(10.3.6) B61623-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発 11gリリース1(10.3.6) B61623-04 |
|
前 |
次 |
監査とは、一連のリクエストの操作や結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。WebLogic Serverでは、監査はコンピュータのアクティビティの電子的な記録を提供するものです。
以下の節では、監査プロバイダの概念と機能、およびカスタム監査プロバイダの開発手順について説明します。
監査プロバイダを開発する前に、以下の概念を理解しておく必要があります。
監査チャネルは監査プロバイダのコンポーネントで、セキュリティ・イベントを監査すべきかどうかを決定し、サービス品質(QoS)ポリシーに基づいて監査情報を実際に記録します。
各タイプのセキュリティ・プロバイダは、セキュリティ関連イベントの実行前または実行後に、それらのイベントに関する情報を記録するよう構成済みの監査プロバイダにリクエストできます。たとえば、あるユーザーが(アクセス権を持たない)預金口座アプリケーションのwithdrawメソッドにアクセスしようとした場合、認可プロバイダではこの操作を記録するようにリクエストできます。セキュリティ関連イベントは、監査プロバイダの構成で指定されている重大度レベルと一致するか、それを超えた場合にのみ記録されます。
カスタム・セキュリティ・プロバイダから監査イベントをポストする方法については、第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」を参照してください。
図10-1に、監査プロバイダがWebLogicセキュリティ・フレームワークや他のタイプのセキュリティ・プロバイダ(ここでは認証プロバイダ)と対話して、選択されたイベントを監査する仕組みを示します。図の後には、詳しい説明が続きます。
図10-1 監査プロバイダ、WebLogicセキュリティ・フレームワーク、および他のセキュリティ・プロバイダ
監査プロバイダは、次のようにWebLogicセキュリティ・フレームワークと他のタイプのセキュリティ・プロバイダと対話します。
|
注意: 図10-1と以下の説明文では、「他のタイプのセキュリティ・プロバイダ」はWebLogic認証プロバイダとカスタム認証プロバイダです。ただし、これらは第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」の説明のように、開発済みのどのようなタイプのセキュリティ・プロバイダでもかまいません。 |
リソース・コンテナは、ログイン・リクエストの一部としてユーザーの認証情報(ユーザー名とパスワードの組合せなど)をWebLogicセキュリティ・フレームワークに渡します。
WebLogicセキュリティ・フレームワークは、ログイン・リクエストに関連付けられている情報を構成済みの認証プロバイダに渡します。
認証サーバーが認証サービスを提供するほかに監査イベントをポストする場合、各認証プロバイダは以下のことを行います。
AuditEventオブジェクトをインスタンス化します。AuditEventオブジェクトには、少なくとも監査対象のイベント・タイプに関する情報と監査の重大度レベルが含まれます。
|
注意: AuditEventクラスを作成するには、カスタム認証プロバイダがすでに実装している必要がある他のセキュリティ・サービス・プロバイダ・インタフェース(SSPI)に加えて、認証プロバイダのランタイム・クラスにAuditEvent SSPIまたはAuditEventコンビニエンス・インタフェースを実装します。監査イベントとAuditEvent SSPI/コンビニエンス・インタフェースについては、「監査イベントの作成」を参照してください。 |
監査サービスに対して信頼性のある呼出しを行って、AuditEventオブジェクトを渡します。
|
注意: ここで信頼性のある呼出しとするのは、監査サービスがすでにセキュリティ・プロバイダのinitializeメソッドに「Provider」SSPI実装の一部として渡されているからです。詳細については、「「Provider」SSPIの目的について」を参照してください。 |
監査サービスは、AuditEventオブジェクトを構成済みの監査プロバイダのランタイム・クラス(AuditChannel SSPI実装)に渡し、監査イベントの記録を有効にします。
|
注意: 認証プロバイダのAuditEventコンビニエンス・インタフェースの実装によっては、監査リクエストがイベントに対して1回発生するだけでなく、イベントの前後にも発生する場合があります。 |
監査プロバイダのランタイム・クラスは、AuditEventオブジェクトから取得したイベント・タイプ、監査重大度、およびその他の情報(監査コンテキストなど)を利用して監査レコードの内容を管理します。一般に、構成済みの監査プロバイダの1つだけがすべての監査条件を満たします。
認証プロバイダによってAuditEventオブジェクト内に指定された監査条件が満たされると、該当する監査プロバイダのランタイム・クラス(AuditChannel SSPI実装)はそれらの実装で指定された方法で監査レコードを書き出します。
|
注意: 監査条件が満たされた際の監査記録の書込み先は、AuditChannel SSPIの実装に応じて、ファイル、データベース、または他の永続ストレージ・メディアになります。 |
ContextHandlerMBean (weblogic.management.security.audit.ContextHandler)は、ContextHandlerがサポートする一連の属性を提供します。このインタフェースを使用すると、コンテキスト・ハンドラ・エントリを標準的な方法でサポートする監査プロバイダを管理できます。
監査プロバイダMBeanは、ContextHandlerMBeanのMBeanを必要に応じて実装できます。監査プロバイダは、このMBeanを使用して、サポートされているアクティブなContextHandlerエントリを判別します。
WebLogic Server管理コンソールは、監査プロバイダがこのMBeanを実装したことを検出して、これらの属性を使用するためのタブを自動的に提供します。
|
注意: ContextHandlerMBeanに関連付けられているContextHandlerエントリは、監査プロバイダに渡されるAuditEventの内容に関連付けられることも、影響を与えることもありません。プロバイダが受信したAuditEventには、ContextElementが指定されたContextHandlerが含まれる場合も含まれない場合もあります。ContextHandlerが含まれている場合、監査プロバイダは、ContextHandlerMBean管理インタフェースを実装したかどうかに関係なくAuditEventからContextHandlerを取得できます。特に、AuditContext getContextメソッドは、ContextHandlerMBeanによって実装されたコンテキスト・ハンドラに依存しないweblogic.security.service.ContextHandlerインタフェースを返します。AuditContext getContextメソッドを補完する形でContextHandlerMBeanコンテキスト・ハンドラを実装するように選択することもできます(サンプルの |
ContextHandlerMBeanインタフェースは、以下のメソッドを実装しています。
getActiveContextHandlerEntries
public String[] getActiveContextHandlerEntries()
現在、監査プロバイダで処理するように構成されているContextHandlerエントリを返します。
getSupportedContextHandlerEntries
public String[] getSupportedContextHandlerEntries()
監査プロバイダによってサポートされているすべてのContextHandlerエントリのリストを返します。
setActiveContextHandlerEntries
public void setActiveContextHandlerEntries(String[] types) throws InvalidAttributeValueException
監査プロバイダで処理するContextHandlerエントリを設定します。指定するエントリは、監査プロバイダのSupportedContextHandlerEntries属性に列挙されているものである必要があります。
例10-5は、サンプル監査プロバイダのランタイム・クラスであるSimpleSampleAuditProviderImpl.javaクラスを示しています。このサンプル監査プロバイダは、ContextHandlerMBeanを実装するように拡張されています。
MBean定義ファイル(MDF)は、WebLogic MBeanMakerユーティリティで、MBeanタイプを構成するJavaファイルを生成するために使用されるXMLファイルです。すべてのMDFでは、作成済みのセキュリティ・プロバイダのタイプに固有の必須SSPI MBeanを拡張する必要があり、さらにオプショナルSSPI MBeanを実装することができます。
例10-1は、任意ContexthandlerMBeanを実装するサンプル監査プロバイダに関連するMDF内の主要なセクションを示しています。
例10-1 例: SimpleSampleAuditor.xml
<MBeanType
Name = "SimpleSampleAuditor"
DisplayName = "SimpleSampleAuditor"
Package = "examples.security.providers.audit.simple"
Extends = "weblogic.management.security.audit.Auditor"
Implements = "weblogic.management.security.audit.ContextHandler"
PersistPolicy = "OnUpdate"
>
...
<MBeanAttribute
Name = "SupportedContextHandlerEntries"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {
"com.bea.contextelement.servlet.HttpServletRequest" }"
Description = "List of all ContextHandler entries
supported by the auditor."
/>
ContextHandlerMBeanにはsetActiveContextHandlerEntriesという属性があり、現在、監査プロバイダで処理するように構成されているContextHandlerエントリをsetActiveContextHandlerEntriesメソッドでこの属性に指定します。指定するエントリは、監査プロバイダのSupportedContextHandlerEntries属性に列挙されているものである必要があります。ただし実際には、MBeanではこの要件が強制されません。この属性にSupportedContextHandlerEntries属性にある値のみを設定できるように検証する処理を、別に行う必要があります。
また、weblogic.management.security.audit.ContextHandlerImplを拡張するMBeanカスタマイザのファイルを(たとえば、MyAuditorImpl.javaという名前で)作成する必要があります。weblogic.management.security.audit.ContextHandlerImplを拡張すると、プロバイダからActiveContextHandlerEntries属性の検証プロバイダへのアクセスが可能になります。この検証プロバイダによって、このエントリに確実にSupportedContextHandlerEntriesにある値のみが含まれるようになります。
ContextHandlerImplの拡張例はSimpleSampleAuditorImplで確認できます。例10-2に示します。
例10-2 SimpleSampleAuditorImpl
package examples.security.providers.audit.simple;
import javax.management.MBeanException;
import javax.management.modelmbean.RequiredModelMBean;
import weblogic.management.security.audit.ContextHandlerImpl;
/**
* The simple sample auditor's mbean implementation.
* <p>
* It is needed to inherit the ContextHandlerMBean's ActiveContextHandlerEntries
* attribute validator that ensures that the ActiveContextHandlerEntries
* attribute only contains values from the SupportedContextHandlerEntries
* attribute.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class SimpleSampleAuditorImpl extends ContextHandlerImpl
// Note: extend ContextHandlerImpl instead of AuditorImpl to inherit
// the ActiveContextHandlerEntries attribute validator.
{
/**
* Standard mbean impl constructor.
*
* @throws MBeanException
*/
public SimpleSampleAuditorImpl(RequiredModelMBean base) throws MBeanException
{
super(base);
}
}
SimpleSampleAuditorImplのようなコードを実装したら、ActiveContextHandlerEntriesを取得するため、実行時の監査プロバイダにコードを追加します。この作業の一例を例10-3に示します。
例10-3 アクティブなコンテキスト・ハンドラ・エントリの取得
String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
if (activeHandlerEntries != null) {
for (int i=0; i<activeHandlerEntries.length; i++) {
if ((activeHandlerEntries[i] != null) &&
(activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
handlerEnabled = true;
break;
}
}
}
WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic監査プロバイダが含まれています。WebLogic監査プロバイダは、WebLogicセキュリティ・フレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。
WebLogic監査プロバイダは、そのwriteEventメソッドで、構成済みの監査重大度レベルとそのメソッドに渡されたAuditEventオブジェクトに格納されている監査重大度に基づいて監査上の決定を行います。(AuditEventオブジェクトの詳細は、「監査イベントの作成」を参照)。
|
注意: WebLogic監査プロバイダに対して構成されている監査重大度レベルは、WebLogic Server管理コンソールで変更できます。詳細は、『Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。 |
一致するものがある場合、WebLogic監査プロバイダはWL_HOME\yourdomain\ yourserver\logsディレクトリにあるDefaultAuditRecorder.logファイルに監査情報を書き込みます。例10-4は、DefaultAuditRecorder.logファイルからの抜粋です。
例10-4 DefaultAuditRecorder.logファイル:出力例
When Authentication suceeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM> <Severity=SUCCESS>
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####
When Authentication fails. [FAILURE]
#### Audit Record Begin <Feb 23, 2005 11:42:01 AM> <Severity=FAILURE>
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####When Operations are invoked.[SUCCESS]
When a user account is unlocked. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM> <Severity=SUCCESS>
<<<Event Type = Authentication Audit Event><TestUser><USERUNLOCKED>>> Audit
Record End ####
When an Authorization request succeeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM> <Severity=SUCCESS>
<<<Event Type = Authorization Audit Event ><Subject: 1
Principal = class weblogic.security.principal.WLSUserImpl("TestUser")
><ONCE><<jndi>><type=<jndi>, application=, path={weblogic}, action=lookup>>>
Audit Record End ####
具体的にいうと例10-4には、ロール・マネージャ(セキュリティ・ロールを専門に扱うWebLogicセキュリティ・フレームワーク・コンポーネント)による監査イベントの記録が示されています。この記録から、権限のある管理者が証明書サーブレット内の保護されたメソッドにアクセスしたことがわかります。
次のJava起動オプションを使用すると、コマンドラインでDefaultAuditRecorder.log用に新しいディレクトリを指定できます。
-Dweblogic.security.audit.auditLogDir=c:\foo
新しいファイルの場所は、c:\foo\yourserver\DefaultAuditRecorder.logです。
監査情報をWebLogicセキュリティ・フレームワークで指定された以外のファイル、またはDefaultAuditRecorder.log以外の出力リポジトリ(異なる名前/場所のシンプル・ファイルまたは既存のデータベース)にも書き込む場合、カスタム監査プロバイダを開発する必要があります。
WebLogic監査プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム監査プロバイダを開発することができます。
ランタイム・クラスを作成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダのランタイム・クラスを作成します。
カスタム監査プロバイダのランタイム・クラスの作成例については、「例:サンプル監査プロバイダのランタイム・クラスの作成」を参照してください。
AuditProvider SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。
getAuditChannel
public AuditChannel getAuditChannel();
getAuditChannelメソッドは、AuditChannel SSPIの実装を取得します。MyAuditProviderImpl.javaという1つのランタイム・クラスの場合、getAuditChannelメソッドの実装は次のようになります。
return this;
ランタイム・クラスが2つの場合、getAuditChannelメソッドの実装は次のようになります。
return new MyAuditChannelImpl;
これは、AuditProvider SSPIを実装するランタイム・クラスが、AuditChannel SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。
AuditProvider SSPIとgetAuditChannelメソッドの詳細は、WebLogic Server APIリファレンスJavadocを参照してください。
AuditChannel SSPIを実装する際には、以下のメソッドの実装を提供する必要があります。
writeEvent
public void writeEvent(AuditEvent event)
writeEventメソッドは、渡されたAuditEventオブジェクト内に指定されている情報に基づいて監査記録を書き込みます。AuditEventオブジェクトの詳細は、「監査イベントの作成」を参照してください。
AuditChannel SSPIとwriteEventメソッドの詳細は、WebLogic Server APIリファレンスJavadocを参照してください。
例10-5は、サンプル監査プロバイダのランタイム・クラスであるSimpleSampleAuditProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。
initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。
getAuditChannelというAuditProvider SSPIから継承したメソッド(「AuditProvider SSPIの実装」を参照)。
writeEventというAuditChannel SSPIのメソッド(「AuditChannel SSPIの実装」を参照)。
例10-5 SimpleSampleAuditProviderImpl.java
package examples.security.providers.audit.simple; import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.PrintStream; import javax.servlet.http.HttpServletRequest; import weblogic.management.security.ProviderMBean; import weblogic.security.service.ContextHandler; import weblogic.security.spi.AuditChannel; import weblogic.security.spi.AuditContext; import weblogic.security.spi.AuditEvent; import weblogic.security.spi.AuditProvider; import weblogic.security.spi.SecurityServices; public final class SimpleSampleAuditProviderImpl implements AuditProvider, AuditChannel { private String description; // a description of this provider private PrintStream log; // the log file that events are written to private boolean handlerEnabled = false; private final static String HTTP_REQUEST_ELEMENT = "com.bea.contextelement.servlet.HttpServletRequest"; public void initialize(ProviderMBean mbean, SecurityServices services) { System.out.println("SimpleSampleAuditProviderImpl.initialize"); SimpleSampleAuditorMBean myMBean = (SimpleSampleAuditorMBean)mbean; description = myMBean.getDescription() + "\n" + myMBean.getVersion(); String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries(); if (activeHandlerEntries != null) { for (int i=0; i<activeHandlerEntries.length; i++) { if ((activeHandlerEntries[i] != null) && (activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) { handlerEnabled = true; break; } } } File file = new File(myMBean.getLogFileName()); System.out.println("\tlogging to " + file.getAbsolutePath()); try { log = new PrintStream(new FileOutputStream(file), true); } catch (IOException e) { throw new RuntimeException(e.toString()); } } public String getDescription() { return description; } public void shutdown() { System.out.println("SimpleSampleAuditProviderImpl.shutdown"); log.close(); } public AuditChannel getAuditChannel() { return this; } public void writeEvent(AuditEvent event) { log.println(event); if ((!handlerEnabled) || (!(event instanceof AuditContext))) return; AuditContext auditContext = (AuditContext)event; ContextHandler handler = auditContext.getContext(); if ((handler == null) || (handler.size() == 0)) return; Object requestValue = handler.getValue("com.bea.contextelement.servlet.HttpServletRequest"); if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest))) return; HttpServletRequest request = (HttpServletRequest) requestValue; log.println(" " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod()); log.println(" " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL()); log.println(" " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI()); return; } }
カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。
この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダのMBeanタイプを作成します。
WebLogic Server環境にMBeanタイプをインストールする
|
注意: この手順の実行方法を説明するサンプル・セキュリティ・プロバイダ(Oracle Technology Network Webサイトのhttps://codesamples.samplecode.oracle.com/servlets/tracking?id=S224から入手可能)がいくつか用意されています。
この節で説明する手順はすべて、Windows環境での作業を想定しています。 |
MBean定義ファイル(MDF)を作成するには、次の手順に従います。
サンプル監査プロバイダのMDFをテキスト・ファイルにコピーします。
|
注意: サンプル監査プロバイダのMDFは、SampleAuditor.xmlという名前です。 |
MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム監査プロバイダに合わせて修正します。
カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。
ファイルを保存します。
MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。
MBeanタイプの生成手順は、カスタム監査プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。
カスタム監査プロバイダのMDFにカスタム操作を含めない場合、次の手順に従います。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
|
注意: バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。 |
カスタム監査プロバイダのMDFにカスタム操作を含める場合、質問に答えながら手順を進めてください。
MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
|
注意: バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。 |
MDFのすべてのカスタム操作に対して、メソッド・スタブを使用してメソッドを実装します。
ファイルを保存します。
既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:
WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。
xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。
-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。
|
注意: WebLogic MBeanMakerではMDFを一度に1つ処理します。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要があります。 |
MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。
完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。
このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。
MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。
WebLogic MBeanMakerでは、作成済みのMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでSampleAuditor MDFを実行すると、SampleAuditorMBean.javaというMBeanインタフェース・ファイルが生成されます。
WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム監査プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。
カスタム監査プロバイダのMJFを作成するには、次の手順に従います。
新しいDOSシェルを作成します。
次のコマンドを入力します。
java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを格納するJARファイルをビルドする必要があることを示し、jarfileはMJFの名前、<filesdir>はWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所です。
この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。
|
注意: カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。 |
生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。
MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム監査プロバイダが「デプロイ」されます。つまり、カスタム監査プロバイダをWebLogic Server管理コンソールから管理できるようになります。
|
注意: MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。
たとえば、 |
カスタム監査プロバイダを構成することによって(「Configure the Custom Auditing Provider Using the 管理コンソール」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。
カスタム監査プロバイダを構成するということは、監査サービスを必要とするセキュリティ・プロバイダがアクセス可能なセキュリティ・レルムにカスタム監査プロバイダを追加するということです。
カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この節では、カスタム監査プロバイダの構成担当者向けの重要な情報を取り上げます。
|
注意: WebLogic Server管理コンソールを使用してカスタム監査プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。 |
構成手順では、監査プロバイダの監査重大度を下記の重大度レベルのいずれかに設定する必要があります。
INFORMATION
WARNING
ERROR
SUCCESS
FAILURE
この節では、WebLogic Serverのセキュリティ・フレームワークによってポストされる監査イベントについて説明します。カスタム監査プロバイダを記述する場合、こうした監査イベントを処理できるようにしておく必要があります。この節では、以下の内容について説明します。
WebLogicセキュリティ・プロバイダは適切なAuditEventインタフェースを実装し、イベントを監査プロバイダにポストします。AuditContextインタフェースも実装する監査イベントでは、ContextHandlerを介してより多くの情報を提供できます。
表10-1に、AuditEvent SSPIを拡張するweblogic.security.spiサブインタフェースと、どのサブインタフェースがAuditContextインタフェースを実装しているかを示します。
表10-1 監査イベント
| 監査イベント名 | インタフェース・クラス | 監査イベント | 監査コンテキスト |
|---|---|---|---|
|
アプリケーション・バージョン・イベント |
|
はい |
いいえ |
|
認証監査イベント |
|
はい |
いいえ |
|
認証監査イベントV2 |
|
はい |
はい |
|
認可監査イベント |
|
はい |
はい |
|
証明書パス・ビルダー監査イベント |
|
はい |
はい |
|
証明書パス検証監査イベント |
|
はい |
はい |
|
構成監査イベント |
|
はい |
はい |
|
資格証明マッピング監査イベント |
|
はい |
はい |
|
ライフ・サイクル・イベント |
|
はい |
いいえ |
|
管理監査イベント |
|
はい |
いいえ |
|
ポリシー監査イベント |
|
はい |
いいえ |
|
ポリシー・コンシューマ監査イベント |
|
AuditPolicyEvent |
いいえ |
|
プロバイダ監査記録 |
|
はい |
はい |
|
ロール・コンシューマ監査イベント |
|
AuditRoleEvent |
はい |
|
ロール・デプロイメント監査イベント |
|
はい |
いいえ |
|
ロール・マッピング監査イベント |
|
はい |
はい |
WebLogicセキュリティでは、weblogic.security.spiパッケージの最上位に1つの基本インタフェース(AuditEvent)が定義され、ここから派生したインタフェース群が様々なタイプの監査イベントを表します。
以降の節では、セキュリティ・フレームワークおよびセキュリティ・プロバイダが以下の監査イベントをいつポストするかについて説明します。
AuditApplicationVersionEvent
AuditAtnEventV2
AuditAtzEvent
AuditCerPathBuilderEvent、AuditCertPathValidatorEvent
AuditConfigurationEvent (AuditCreateConfigurationEvent、AuditDeleteConfigurationEvent、AuditInvokeConfigurationEvent、AuditSetAttributeConfigurationEvent)
AuditCredentialMappingEvent
AuditLifecycleEvent
AuditMgmtEvent
AuditPolicyEvent (AuditEndPolicyDeployEvent、AuditPolicyDeleteAppEvent、AuditPolicyDeployEvent、AuditPolicyUndeployEvent、AuditResourceProtectedEvent、AuditStartPolicyDeployEvent、PolicyConsumerAuditEvent)
AuditRoleDeploymentEvent (AuditStartRoleDeployEvent、AuditEndRoleDeployEvent、AuditRoleUndeployEvent、AuditRoleDeleteAppEvent)
AuditRoleEvent (RoleConsumerAuditEvent)
アプリケーション・バージョンの監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString = "Application Version Audit Event"です。
表10-2で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
表10-2 アプリケーション・バージョン・イベント
| コンポーネント | 説明 | 重大度 |
|---|---|---|
|
セキュリティ・フレームワーク |
このイベントはセキュリティ・フレームワークにより以下の理由でポストされます。
|
SUCCESSまたはFAILURE |
認証監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = Authentication Audit Event"です。
表10-3で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
表10-3 認証監査イベント
| コンポーネント | 説明 | 重大度 |
|---|---|---|
|
セキュリティ・フレームワーク |
ユーザーの認証が成功した後にポストされます。 |
SUCCESS |
|
セキュリティ・フレームワーク |
認証が失敗した後にポストされます(JAASログイン・メソッドからLoginExceptionがスローされます)。このLoginExceptionはJAASフレームワークによってスローされる場合と、WebLogic Server認証プロバイダのJAAS LoginModuleによってスローされる場合があります。 |
FAILURE |
|
セキュリティ・フレームワーク |
匿名ユーザーに対するIDアサーションの後にポストされます。 |
SUCCESS |
|
セキュリティ・フレームワーク |
IDアサーションが失敗した後にポストされます(IDアサーション・メソッドからIdentityAssertionExceptionがスローされます)。 |
FAILURE |
|
セキュリティ・フレームワーク |
IDアサーションが失敗した後にポストされます(コールバックからのユーザー名の取得時にIDアサーション・コールバック・ハンドラによってIOExceptionがスローされます)。 |
FAILURE |
|
セキュリティ・フレームワーク |
IDアサーションが失敗した後にポストされます(コールバックからのユーザー名の取得時にIDアサーション・コールバック・ハンドラによってUnsupportedCallbackExceptionがスローされます)。 |
FAILURE |
|
セキュリティ・フレームワーク |
IDアサーションが失敗した後にポストされます(IDアサーション・コールバック・ハンドラから返されたユーザー名がnullまたは長さゼロである場合)。 |
FAILURE |
|
セキュリティ・フレームワーク |
IDアサーションが成功した後にポストされます。 |
SUCCESS |
|
セキュリティ・フレームワーク |
IDアサーションが失敗した後にポストされます。 |
FAILURE |
|
セキュリティ・フレームワーク |
なりすましID (匿名ID)が成功した後にポストされます。 |
SUCCESS |
|
セキュリティ・フレームワーク |
なりすましIDが成功した後にポストされます。 |
SUCCESS |
|
セキュリティ・フレームワーク |
なりすましIDが失敗した後にポストされます。 |
FAILURE |
|
セキュリティ・フレームワーク |
プリンシパル検証が失敗した後にポストされます。 |
FAILURE |
認可監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = Authorization Audit Event V2 "です。
表10-4で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
証明書パス・ビルダーおよび証明書パス検証の監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列は次のとおりです。
String eventType = "Event Type = CertPathBuilder Audit Event "
String eventType = "Event Type = CertPathValidator Audit Event "
表10-5で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
構成監査イベントはセキュリティ・フレームワークによってポストされます。以下のイベントがポストされます。
AuditConfigurationEvent
AuditCreateConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString CREATE_EVENT = "Create Configuration Audit Event")
AuditDeleteConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString DELETE_EVENT = "Delete Configuration Audit Event")
AuditInvokeConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString INVOKE_EVENT = "Invoke Configuration Audit Event")
AuditSetAttributeConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString SETATTRIBUTE_EVENT = "SetAttribute Configuration Audit Event")
表10-6で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
表10-6 構成監査イベント
| コンポーネント | 説明 | 重大度 |
|---|---|---|
|
WebLogic管理インフラストラクチャ |
WebLogic管理インフラストラクチャがこのインタフェースを実装し、以下の構成変更イベントについて構成監査イベントをポストできます。
|
SUCCESSまたはFAILURE |
資格証明マッピング監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString EVENT_TYPE = "Event Type = Credential apping Audit Event"です。
表10-7で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
AuditLifecycleEventインタフェースは監査のライフサイクルのイベントをポストするために使用されます。WebLogicセキュリティ・フレームワークがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストできます。
フレームワークの監査サービスの起動後。
フレームワークの監査サービスの停止前。
getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = AuditLifecycle Audit Event"です。
AuditLifecycleEventTypeクラスに、サポートされる監査サービス・ライフサイクル・イベントのタイプが記述されます。有効な値はSTART_AUDITおよびSTOP_AUDITです。
監査プロバイダではこのインタフェースを使用して、監査のライフサイクルのイベントに関する付加的な情報を取得できます。AuditSeverityおよびAuditLifecycleEventType属性を使用すると、前述の監査イベントのうち、どちらがポストされたかを判断できます。
管理監査イベントは、現在、セキュリティ・フレームワークおよび提供されているプロバイダのいずれでもポストされません。ただしカスタム・セキュリティ・プロバイダでは、このインタフェースを実装して、自身が実行する様々な管理操作に対し種々の監査イベントをポストできます。
監査プロバイダではこのインタフェースを使用して、管理監査イベントに関する付加的な情報を取得できます。AuditSeverity属性を使用すると、管理操作が成功したか、失敗したかを判断できます。
AuditPolicyEventは、セキュリティ・フレームワークおよびWebLogic認可プロバイダによってポストされます。セキュリティ・フレームワークでは、ポリシーが認可プロバイダに対してデプロイまたはアンデプロイされたときにポリシー監査イベントをポストします。WebLogic Server認可プロバイダでは、ポリシーを作成、削除または更新したときにポリシー監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。この監査イベント群と、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。
AuditStartPolicyDeployEvent (から返される実際の監査情報の文字列はgetEventType String eventType = "Event Type = Authorization Start Policy Deploy Audit Event ")。
AuditPolicyUndeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Policy Undeploy Audit Event ")。
AuditPolicyDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Policy Deploy Audit Event ")。
AuditPolicyDeleteAppEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Delete Application Policies Audit Event ")。
AuditEndPolicyDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization End Policy Deploy Audit Event ")。
AuditPolicyEventを実装するPolicyConsumerAuditEventの場合、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。
String eventType = "Event Type = Policy Consumer Get Handler"
String eventType = "Event Type = Policy Consumer Set Policy"
String eventType = "Event Type = Policy Consumer Set Unchecked Policy"
String eventType = "Event Type = Policy Consumer Done"
表10-8で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
表10-8 ポリシー監査イベント
| コンポーネント | 説明 | 重大度 |
|---|---|---|
|
WebLogic認可プロバイダ |
|
SUCCESSまたはFAILURE |
セキュリティ・フレームワークでは、ロールがロール・マッピング・プロバイダに対してデプロイまたはアンデプロイされたときにロール・デプロイメント監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。以下のイベントがポストされます。
AuditRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Deploy Audit Event ")。
AuditStartRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Start Deploy Role Audit Event ")。
AuditEndRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager End Deploy Role Audit Event ")。
AuditRoleUndeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Undeploy Audit Event ")。
表10-9で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
表10-9 ロール・デプロイメント監査イベント
| コンポーネント | 説明 | 重大度 |
|---|---|---|
|
セキュリティ・フレームワーク |
WebLogicセキュリティ・フレームワークがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストできます。
|
SUCCESSまたはFAILURE |
WebLogic認可プロバイダでは、ロールが作成、削除または更新されたときにロール監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列は次のとおりです。
String eventType = "Event Type = RoleManager Audit Event "
String eventType = "Event Type = RoleManager Delete Application Roles Audit Event "
AuditRoleEventを実装するRoleConsumerAuditEventの場合、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。
String eventType = "Event Type = Role Consumer Get Handler"
String eventType = "Event Type = Role Consumer Set Role"
String eventType = "Event Type = Role Consumer Done"
表10-10で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。
