7 WebLogic監査プロバイダの構成
この章の内容は次のとおりです。
監査プロバイダの概要
監査プロバイダの構成はオプションです。デフォルト・セキュリティ・レルム(myrealm
)には監査プロバイダは構成されていません。WebLogic Serverには、WebLogic監査プロバイダ(WebLogic Server管理コンソールではDefaultAuditor
)というプロバイダが用意されています。また、カスタム監査プロバイダを開発することもできます。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の監査プロバイダに関する項を参照してください。
WebLogic監査プロバイダによってログに記録されるイベント
表7-1 WebLogic監査プロバイダのイベント
監査イベント | 意味 |
---|---|
AUTHENTICATE |
単純認証(ユーザー名とパスワード)が発生しました。 |
ASSERTIDENTITY |
境界認証(トークン・ベース)が発生しました。 |
USERLOCKED |
無効なログイン試行によってユーザー・アカウントがロックされました。 |
USERUNLOCKED |
ユーザー・アカウントのロックがクリアされました。 |
USERLOCKOUTEXPIRED |
ユーザー・アカウントのロックの期限が切れました。 |
ISAUTHORIZED |
認可処理の試行が発生しました。 |
ROLEEVENT |
|
ROLEDEPLOY |
|
ROLEUNDEPLOY |
|
POLICYDEPLOY |
|
POLICYUNDEPLOY |
|
START_AUDIT |
監査プロバイダが起動しました。 |
STOP_AUDIT |
監査プロバイダが停止しました。 |
構成オプション
-
ローテーション時間(分) - 新しい
DefaultAuditRecorder.log
ファイルを作成するまでの分数を指定します。指定された時間が経過すると、監査ファイルが閉じられて新しい監査ファイルが作成されます。DefaultAuditRecorder.
YYYYMMDDHHMM
.log
(たとえば、DefaultAuditRecorder.200405130110.log
)という名前のバックアップ・ファイルが同じディレクトリ内に作成されます。 -
重大度 - WebLogic Serverデプロイメントに適した重大度です。WebLogic監査プロバイダは、指定された重大度のセキュリティ・イベント、およびそれより高い重大度のすべてのイベントを監査します。たとえば、重大度ERRORに設定した場合、WebLogic監査プロバイダは重大度がERROR、SUCCESS、およびFAILUREのセキュリティ・イベントを監査します。重大度をCUSTOMに設定すると、監査の必要な特定の重大度レベル(ERRORイベント、FAILUREイベントのみなど)を対象にすることもできます。監査イベントには、重大度の名前と数値順位が含まれています。このため、カスタム監査プロバイダは、名前または数値順位のいずれかによってイベントをフィルタ処理できます。監査は、以下のレベルのセキュリティ・イベントが発生したときに実行されます。
表7-2 イベントの重大度
イベントの重大度 ランク INFORMATION
1
WARNING
2
ERROR
3
SUCCESS
4
FAILURE
5
WebLogic監査プロバイダによって記録されるすべての監査情報は、デフォルトではWL_HOME
\yourdomain\yourserver\logs\DefaultAuditRecorder.log
に保存されます。監査プロバイダはセキュリティ・レルム単位で構成されますが、各サーバーは監査データをサーバー・ディレクトリにある各自のログ・ファイルに書き込みます。次のJava起動オプションを使用すると、コマンド・ラインでDefaultAuditRecorder.log
用に新しいディレクトリを指定できます。
-Dweblogic.security.audit.auditLogDir=c:\foo
新しいファイルの場所は、c:\foo\yourserver\logs\DefaultAuditRecorder.log
になります。
『Oracle WebLogic Serverコマンド・リファレンス』のセキュリティに関する項を参照してください。
ノート:
監査プロバイダを使用すると、わずか数個のイベントのログが記録される際にもWebLogic Serverのパフォーマンスに影響が及びます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。
ContextHandler要素の監査
ContextHandler
インタフェースは、コンテキスト・ハンドラ・エントリをサポートする監査プロバイダを管理するために使用されます。ContextHandler
Entries属性を設定すると、どのContextElementエントリが監査プロバイダによって記録されるかを指定できます。
監査イベントには、様々な情報やオブジェクトを保持できるContextHandler
が組み込まれています。WebLogic監査プロバイダのActive ContextHandler Entries
属性を設定すると、ContextHandler
内のどのContextElementエントリが監査プロバイダによって記録されるかを指定できます。デフォルトでは、どのContextElementsも監査されません。ContextHandler
内のオブジェクトは、ほとんどの場合toStringメソッドを使用してログに記録されます。表7-3に、利用できるContextHandler
エントリの一覧を示します。
ノート:
WebLogic監査プロバイダでは、実装されている特定の機能に関する属性のみを監査できます。デフォルトでは、すべてのコンテキスト・ハンドラ要素を監査できるわけではありません。たとえば、HTTPを使用してWebLogic Server管理コンソールにログインしている場合、認証はHTTPサーブレット・リクエストのコンテキストにおいて実行され、監査プロバイダではHTTPサーブレットの要素が監査されます。あるいは、WLSTからの認証では、t3プロトコルが使用されます。t3認証の場合、監査プロバイダでは、com.bea.contextelement.channel.Protocol
やcom.bea.contextelement.channel.RemoteAddress
などのチャネル・コンテキスト要素が監査されます。いずれの場合も、監査プロバイダでは、実装されている機能(HTTPまたはt3)のみが監査されます。
表7-3 監査用のコンテキスト・ハンドラ・エントリ
コンテキスト要素名 | 説明とタイプ |
---|---|
|
HTTPによるサーブレット・アクセス・リクエストまたはSOAPメッセージ。
|
|
HTTPによるサーブレット・アクセス・レスポンスまたはSOAPメッセージ。
|
|
Oracle WebLogic Integrationメッセージ。メッセージは監査ログに送られます。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・ポート。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・ポート。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・エンドのポート。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルのリクエストを行うためのプロトコル。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・アドレス。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・アドレス。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・アドレス。
|
|
リクエストの受け付けまたは処理を行うネットワーク・チャネルの名前。
|
|
SSLによるリクエストの受け付けまたは処理を行うネットワーク・チャネルかどうかを示します。
|
|
パラメータに基づくオブジェクト。 |
|
|
|
WebLogic Serverの内部プロセスで使用されます。
|
|
SSLフレームワークが証明書チェーンを検証しました。つまり、チェーン内の証明書が相互に適切に署名しており、チェーンが終了する証明書がサーバーの信頼性のあるCAの1つであり、チェーンが基本制約ルールに準拠していて、チェーン内の証明書が期限切れではありませんでした。
|
|
このリリースのWebLogic Serverでは使用されません。
|
|
このリリースのWebLogic Serverでは使用されません。
|
|
|
|
SSLクライアント証明書チェーンがSSL接続から取得され、sender-vouches SAMLアサーションが受信されました。
|
|
Webサービス・メッセージに署名するための証明書。
|
|
SAMLアサーションのタイプ(bearer、artifact、sender-vouches、holder-of-key)。
|
|
holder-of-key SAMLアサーションでのサブジェクト確認のために使用される
|
構成監査
構成監査メッセージは、管理サーバーのローカル・ログ・ファイルに書き込まれます。デフォルトではドメイン全体のメッセージ・ログには書き込まれません。
構成監査情報は、認可イベントに格納されます。そのため、認可イベントを消費して構成監査情報にアクセスする方法もあります。ただし、認可イベント内の情報は構成の変更の実行が許可されたかどうかを示すものであり、構成の変更が実際に成功したかどうかは示されません(たとえば、変更が無効だったため失敗してしまっている場合もあります)。
構成監査を有効化するには、構成監査の有効化を参照してください。
構成監査の有効化
構成監査の有効化は、以下のいずれかの方法で行えます。
-
WebLogic Server管理コンソールを使用する。ドメインの「構成」→「全般」ページで、「構成監査のタイプ」を設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの構成監査の有効化に関する項を参照してください。
-
管理サーバーの起動時に、
weblogic.Server
コマンドに次のJavaオプションのいずれかを含めます。-
-Dweblogic.domain.ConfigurationAuditType="audit"
ドメインによって監査イベントのみが送信されます。
-
-Dweblogic.domain.ConfigurationAuditType="log"
ドメインによって構成監査メッセージのみが管理サーバーのログ・ファイルに書き込まれます。
-
-Dweblogic.domain.ConfigurationAuditType="logaudit"
ドメインによって監査イベントが送信され、構成監査メッセージが管理サーバーのログ・ファイルに書き込まれます。
『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。
-
-
WebLogic Scripting Toolを使用して、
DomainMBean
のConfigurationAuditType
属性の値を変更します。『WebLogic Scripting Toolの理解』を参照してください。
構成監査メッセージ
構成監査の重大度レベルは、SUCCESS
、FAILURE
およびERROR
です。
表7-4 構成監査メッセージの重大度
Severity | 説明 |
---|---|
SUCCESS |
構成の変更が正常に行われました。 |
FAILURE |
ユーザーの資格証明が十分でなかったため構成が変更されませんでした。 |
ERROR |
内部エラーのため構成が変更されませんでした。 |
構成監査メッセージは、159900 - 159910
の範囲のメッセージIDで識別されます。
構成監査メッセージでは、MBeanオブジェクト名を使用してリソースを特定します。WebLogic Server MBeanのオブジェクト名は、階層データ・モデル内でのMBeanの場所を反映しています。この場所を反映させるために、オブジェクト名には親MBeanからの名前と値のペアが含まれています。たとえば、サーバーのLogMBean
のオブジェクト名は、mydomain:Name=myserverlog
,Type=Log,Server=myserver
です。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanのデータ・モデルに関する項を参照してください。
表 7-5に、これらのメッセージをまとめます。
表7-5 構成監査メッセージの概要
発生したイベント | WebLogic Serverにより生成されるメッセージのID | メッセージのテキスト |
---|---|---|
認可されたユーザーがリソースを作成します。 |
|
ここで、 |
認可されていないユーザーがリソースを作成しようとします。 |
|
ここで、 |
認可されたユーザーがリソースを削除します。 |
|
ここで、 |
認可されていないユーザーがリソースを削除しようとします。 |
|
ここで、 |
認可されたユーザーがリソースの構成を変更します。 |
|
ここで、 |
認可されていないユーザーがリソースの構成を変更しようとします。 |
|
ここで、 |
認可されたユーザーがリソース操作を呼び出します。 たとえば、ユーザーがアプリケーションをデプロイするか、サーバー・インスタンスを起動します。 |
|
ここで、 |
認可されていないユーザーがリソース操作を呼び出そうとします。 |
|
ここで、 |
認可されたユーザーが構成監査を有効にします。 |
|
ここで、 |
認可されたユーザーが構成監査を無効にします。 |
|
ここで、usernameは構成監査を無効にしたWebLogic Serverユーザーを示します。 |
ノート:
構成監査が有効かどうかに関係なく、認可されたユーザーがリソースを追加、変更、または削除するたびに、管理サブシステムからも重大度InfoのメッセージがID 140009で生成されます。たとえば:
<Sep 15, 2005 11:54:47 AM EDT> <Info> <Management> <140009> <Configuration changes for domain saved to the repository.>
このメッセージでは、ドメインの構成が変更されたことは分かりますが、構成監査メッセージのような詳細情報は提供されません。また、このメッセージは、リソース操作を呼び出したときには生成されません。
表7-6に、構成監査メッセージの他のメッセージ属性をまとめます。これらの属性は、すべての構成監査メッセージで共通です。
表7-6 共通のメッセージ属性と値
メッセージ属性 | 属性値 |
---|---|
Severity |
|
サブシステム |
|
ユーザーID |
この値は、どのユーザーがリソースの変更やリソース操作の呼出しを実行しても常に |
サーバー名 |
ドメイン内のすべてのリソースの構成データが管理サーバーに保持されているため、この値は常に管理サーバーの名前になります。 |
マシン名 |
ドメイン内のすべてのリソースの構成データが管理サーバーに保持されているため、この値は常に管理サーバーのホスト・マシンの名前になります。 |
スレッドID |
この値は、管理サーバーで現在実行されている実行スレッドの数によって異なります。 |
タイムスタンプ |
メッセージが生成されたときの |
監査イベントと監査プロバイダ
ドメインで監査イベントの送信を有効にすると、イベントが送信されます(表7-7を参照)。ドメインに対して構成されているすべての監査プロバイダは、これらのイベントを処理できます。
イベントの重大度はすべてSUCCESS
になり、アクションを開始したセキュリティ・プリンシパル、権限が付与されていたかどうか、およびリクエストされたアクションのオブジェクト(MBeanまたはMBean属性)が示されます。
表7-7 構成監査の監査イベントのサマリー
発生したイベント | WebLogic Serverにより生成される監査イベント・オブジェクト |
---|---|
新しい構成アーティファクトを作成するリクエストが許可または回避されました。 |
|
既存の構成アーティファクトを削除するリクエストが許可または回避されました。 |
|
既存の構成アーティファクトを変更するリクエストが許可または回避されました。 |
|
既存の構成アーティファクトに対する操作の呼出しが許可または回避されました。 |
デフォルトのWebLogic Server監査プロバイダを有効にすると、すべての監査イベントがログ・メッセージとしてその独自のログ・ファイルに書き込まれます。
作成または購入されたその他の監査プロバイダは、これらのイベントをフィルタ処理して、それらをLDAPサーバー、データベース、シンプル・ファイルなどの出力リポジトリに書き出すことができます。さらに、他のタイプのセキュリティ・プロバイダは、監査プロバイダからの監査サービスをリクエストできます。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の監査プロバイダに関する項を参照してください。