| Oracle® Enterprise Managerライフサイクル管理ガイド 12cリリース5 (12.1.0.5) B66837-13 |
|
 前 |
 次 |
Oracle Enterprise Manager Cloud Control (Cloud Control)のコンプライアンス機能を使用すると、ターゲットの特定の要素をリアルタイムで監視して、構成変更または構成変更につながるアクションを検分できます。
これらの機能には、オペレーティング・システム・レベルのファイル変更の監視、プロセスの開始と停止、オペレーティング・システムのユーザー・ログインおよびログアウト、Oracleデータベースの変更などがあります。
これらの機能のリアルタイム監視は、Cloud Controlエージェントから行います。この機能の中には、実行する監視のタイプや監視対象のオペレーティング・システムに応じて特定の設定手順を必要とするものもあります。
この項では、コンプライアンスのリアルタイム監視機能を使用するための特定の要件および前提条件について概説します。Cloud Controlからリアルタイム監視を使用する方法の詳細は、このドキュメントのコンプライアンス管理に関する章を参照してください。この章の構成は、次のとおりです。
リアルタイム監視は、Cloud Controlサーバーを使用して構成します。EM_COMPLIANCE_DESIGNERロールを持つユーザーは、「リアルタイム監視ルール」タイプのコンプライアンス標準ルールを作成します。これらのルールはコンプライアンス標準と関連付けられ、続いてこれらの標準が1つ以上のターゲットに関連付けられます。
コンプライアンス標準とターゲットの関連付けが完了すると、一連の監視ルールがエージェントに送信されて、リアルタイム監視が有効になります。リアルタイム監視の監視はすべてエージェントで行われ、監視されたアクション・データはすべてエージェントからCloud Controlサーバーに送信され、レポートやデータ管理に使用されます。
リアルタイム監視機能は、Cloud Controlエージェントに組み込まれています。リアルタイム監視機能を使用する場合、リソースに関する特定の考慮事項がいくつかあります。次の項では、リアルタイム監視機能を使用する際に考慮が必要な事項について説明します。
ファイル変更をリアルタイムで監視する際は、オプションでエージェントにファイルのアーカイブ・コピーを作成するように設定できます。監視が最初に開始されると、その時点のファイルのコピーが作成されて、エージェントのORACLE_HOMEディレクトリ内のプライベート・ディレクトリに格納されます。その後は、そのファイルを変更すると、ファイルの追加コピーがその同じディレクトリ内にアーカイブされます。この機能を使用すると、後でユーザー・インタフェースからファイル差分を実行したり、ファイルを前のバージョンにロールバックするジョブを発行できます。
ただし、この機能では、ファイルのコピーを作成するためにディスク領域が使用されます。この機能は非常に重要なファイルに対してのみ有効にするように注意してください。作成時には、保存するファイルのコピー数を指定できます。デフォルトは5つの履歴バージョンです。これを調整することにより、潜在的なリソース消費をチューニングすることもできます。
Oracleデータベースの監視モジュールを初めて実行する際に以前のOracleデータベースの変更イベントをすべて無視するには、「ルール前のイベントを無視」フィールドでチェック・ボックスを選択します。
オペレーティング・システム・ファイル・レベルの監視では多くのタイプのファイル変更を監視できますが、ファイル読取りの監視も可能です。ファイル・パターンが頻繁に読み取られるファセットを監視するルールを使用すると、非常に多数の監視が生成されることがあります。監視の数を減らすには、ファイルを読み取ることのない時間またはユーザーに対するフィルタがルールに適用されていることを確認します。
たとえば、すべてのユーザーによる/etc/passwdファイルの読取りを監視すると、多数の監視が作成されます。しかし、特定のユーザーに関する/etc/passwdファイルのみを監視すれば、ルール作成時にその特定のユーザーに対するユーザー・フィルタを作成できます。これにより、その特定のユーザーがファイルの読取りを試行したときにのみ監視が送信されるようになります。
ファセットは、セキュリティまたはコンプライアンスの目的で監視することが重要なファイルを指定するために作成するものですので注意してください。インスタンスの場合、数秒ごとに変化するログ・ファイルへの変更内容をすべて監視すると、レポートするファイルの変更点の数が多くなるため、確認する必要がある重要なファイルの変更点を識別するのが困難になってしまいます。この場合は、ログ・ファイルのすべての変更を監視するルールを作成し、非アプリケーション・ユーザーによりログ変更が行われた場合にのみフィルタ処理することをお薦めします。こうすることで、アプリケーションによりログ・ファイルが更新された場合は除外され、一般ユーザーがログの変更や改ざんを試行した場合のみログ・ファイル変更が取得されます。
リアルタイム監視でのデータベース・サイジングに関する考慮事項は、いくつかの要因に依存します。最も重要な要因は、予測される1か月当たりの監視数です。2番目の要因は、データがリポジトリに保存される月数です。リポジトリの保存率については、Enterprise Manager管理ガイドを参照してください。
一般に、1回の監視でデータベースの領域が約1.5KB消費されます。これはガイドラインであり、各インストールで多くの要因に応じて様々に異なります。
たとえば、すべてのターゲットにわたるリアルタイム監視数が月当たり合計1,000万件で、データの保存期間が12か月である場合、必要なデータベース・サイズは約180GBです。
10,000,000(監視)x 12(月)x 1500(バイト)= 180,000,000,000(バイト)
このサイズはリアルタイム監視データのみを表したものであり、他のCloud Control領域に必要なデータベース記憶域要件は含まれていません。
月当たりの予測監視数は環境によって異なり、また構成する監視のタイプによっても異なります。ルールおよびファセットを一定期間有効にし、組織の要件に合うように構成した後で、時間をかけて予測サイズを調整する必要があることがあります。1か月間の監視使用量を調べるには、「エンタープライズ」メニューから「コンプライアンス」を選択し、「リアルタイム監視」ページからシステムによる参照のUIレポートを選択してシステムを選択し、一定の期間の各システムの関連する監視数を表示します。
リアルタイム監視機能の多くには監視資格証明が必要であり、これにより常にルート権限で監視プログラムを起動できます。リアルタイム監視で使用されるこれらのプロセスの先頭には接頭辞nmxcがあります。低レベルの監視では、一般ユーザーには使用できないオペレーティング・システムAPIが使用されます。
ターゲット・ホストでリアルタイム監視機能の使用を開始する前に、Enterprise Managerコンソールから次の設定を構成しておく必要があります。
エージェントのインストール後にエージェントのroot.shスクリプトが実行されていることを確認します。
エージェントのインストール後、ルート・ユーザーとしてroot.shスクリプトを実行する必要があります。以降の資格証明手順を構成する前に、このスクリプトを実行する必要があります。
権限委任を構成します。
「権限委任」設定を表示するには、「設定」メニューから「セキュリティ」、「権限委任」の順に選択します。このページでは、各ホストの権限委任を手動で設定することも、権限委任設定テンプレートを作成することもできます。
リアルタイム監視を行う各ホストに権限委任を設定するには、適切なSUDOコマンド(/usr/local/bin/sudoなど)を入力してSUDO設定を有効にする必要があります。
監視資格証明を構成します。
「監視資格証明」設定には、「設定」メニューからアクセスできます。「セキュリティ」、「監視資格証明」の順に選択します。このページから、「ホスト」ターゲット・タイプを選択し、「監視資格証明の管理」をクリックします。
「リアルタイム構成変更監視のホスト資格証明」の資格証明が設定されている各エントリについて、エントリを選択して「資格証明の設定」をクリックします。使用する資格証明を指定するように要求されます。また、必ず「別名実行」エントリにrootを追加してください。「別名実行」が表示されない場合は、前の手順で権限委任が適切に設定されていないということです。
複数のホストに対して資格証明の一括監視を一度に設定するには、EMCLIを使用できます。EMCLIを使用した監視資格証明の設定の詳細は、『Oracle Enterprise Manager管理』のセキュリティに関する章でEMCLIを使用した資格証明の管理に関する項を参照してください。また、Cloud Controlでの監視資格証明の構成の詳細は、『Oracle Enterprise Manager管理』のセキュリティに関する章を参照してください。
次の各項では、Linuxホストを監視する準備を行う方法について説明します。
Linuxのリアルタイム・ファイル監視を使用する前に、ロード可能なカーネル・モジュールをホストにインストールしておく必要があります。このロード可能カーネル・モジュールは、ホストを監視する最も効率的な手段です。このロード可能カーネル・モジュールは、ファイル監査モジュール(あるいは単に監査モジュール)と呼ばれます。
カーネル・モジュールの取得
カーネル監査モジュールは、http://oss.oracle.com/projects/fileauditmoduleから入手可能です。ファイル監査カーネル・モジュールを取得するには、2つの方法があります。
事前作成.koファイル。Oracleで事前作成されたこのファイルを環境内で使用できます。事前作成カーネル・モジュールは、「ダウンロード」リンクから検索できます。一致する事前作成バージョンを調べるには、監視対象のホストでuname -rコマンドを実行し、そのバージョンを事前作成モジュールのバージョンと比較します。バージョン文字列全部が完全に一致する必要があります。32ビットのマシンの場合、.koファイル名の修正後の名前は.koになります。64ビットのマシンの場合、.koファイル名の修正後の名前は.k64.koになります。
独自のカーネル・モジュールの作成。独自のカーネル・モジュールを作成するには、「ダウンロード」リンクから次のRPMをダウンロードできます。
Fileauditmodule-emversion-revision-noarch.rpm
このモジュールをインストールする際は必ず、その時点で入手可能な最新のリビジョンを取得してください。emversionフィールドは、使用しているCloud Controlエージェントおよびサーバーのバージョンと一致する必要があります。
このRPMをルートとして監視対象ホストにインストールします。このRPMのインストールは、ホストに存在する実行中のカーネルと一致するkernel-develパッケージに依存します。このkernel-develパッケージには、Linuxインストーラと同じメディアが付属しています。
このパッケージをインストールし、さらにホストで使用可能なgccのバージョンがカーネルの作成に使用されたバージョンと一致していることを確認する必要があります。このためには、/proc/versionファイルを参照してカーネルの作成に使用されたgccバージョンを確認し、続いてコマンドgcc –vを実行して使用中のgccバージョンを確認します。これらのバージョンは、一致している必要があります。
また、ファイル/boot/System.map-{version}が存在することを確認します。ここで、{version}は、uname -rコマンドを実行すると表示されるカーネル・バージョンと一致している必要があります。リアルタイムの変更を監視するには、このファイルに含まれるシステム・シンボルが、カーネル・シンボルのデコードのために必要です。このファイルがない場合、リアルタイムのファイル監視は機能しません。このファイルは、すべてのデフォルトのLinuxインストールで標準となっています。
このパッケージのインストールと前提条件のチェックが正常に完了したら、パッケージ・コンテンツがインストールされたディレクトリ(デフォルトでは/opt/fileauditmodule)に移動し、次のスクリプトを実行します。
compmod.sh
これによって、カーネル・モジュール・ファイル(OSのバージョンに応じて拡張子はko、.k64または.oのいずれかになる)が作成され、/opt/fileauditmoduleディレクトリに格納されます。
監査モジュール・ファイルが作成されていない場合は、make.logファイルとbuild.logファイルでモジュール作成のエラーを調べてください。
すべてのホストのカーネル・バージョンが、コマンドuname –rを使用して表示されたカーネル・バージョンと一致していれば、1つのマシンでモジュールをコンパイルするだけで済みます。その後は、.ko、.k64または.oファイルを他のサーバーにコピーできます。これらのファイルを特定のホスト上に作成する必要はありません。
カーネル・モジュールのデプロイ
事前作成.koファイルまたはソースRPMから作成した.koファイルは、適切なディレクトリに配置する必要があります。このファイルのデフォルトの場所は、エージェントのホーム・ディレクトリ内のbinフォルダです。また、このファイルをホスト上の任意の場所に格納して、エージェント・ホームのAGENT_INST/sysman/configディレクトリ内のnmxc.propertiesファイルを変更することもできます。プロパティnmxcf.kernel_module_dirは、.koディレクトリの絶対パスを指定します。
カーネル・モジュールのインストール・ジョブ
エージェントへの.KOファイルの手動配置以外にも、「リアルタイム監視カーネル・モジュールのインストール」という名前のCloud Controlジョブがあります。このジョブは、カーネル・モジュールをインストールできるLinuxホストのリストを使用して構成します。事前作成.koファイルまたはソースRPMファイルが、Cloud Controlサーバー・ディスクのディレクトリでローカルに検索されます。一致する事前作成.koファイルが見つかると、一致するエージェントに送信されます。見つからない場合、RPMがエージェントに送信、インストールおよびコンパイルされ、新しい.KOファイルが生成されます。
このジョブを使用する前に、ユーザーはOSS.ORACLE.COMからファイルを手動で取得して、
%ORACLE_HOME%/gccompliance/fileauditmodule/resources/linuxディレクトリに格納する必要があります。このディレクトリは、このディレクトリがこれらのファイルの格納場所であることを示すREADMEファイルとともに、すでにサーバー上に存在しています。ここに格納する必要のあるファイルは、事前作成.KOファイルまたはソースRPMファイルです。環境内に独自の.KOファイルを作成した場合は、これらの.KOファイルをサーバー上のこのディレクトリに格納して、環境内の他のホストにデプロイすることもできます。
Enterprise Linux 5以上に関する特別な考慮事項
Enterprise Linux 5以上の場合、カーネル監査モジュールは必要ありません。起動時にカーネル・モジュールが検出されない場合、監視には組込みの監査サブシステムが使用されます。ただし、監査サブシステムの機能はカーネル監査モジュールの機能ほど堅牢ではありません。
作成アクションであっても変更アクションであっても、どのようなタイプの変更がファイルに行われたかまでを調べる機能は失われます。カーネル・モジュールがない場合、ファイルに対するすべての変更は変更アクションとみなされます。また、まだ存在しないディレクトリの監視や、現在存在するが後で削除される可能性があるディレクトリの監視は、基礎となるLinux監査サブシステムによってこれらの監視が処理されないため、中断される可能性があります。
新バージョンのLinuxを使用する場合でも、可能であれば、カーネル監査モジュールを使用することをお薦めします。
カーネル・モジュールに関する問題は、次の方法で検出できます。
行われたはずのファイル変更に関して、Enterprise Managerコンソールにリアルタイム・ファイル変更が表示されていない場合があります。
ユーザー・インタフェースの「コンプライアンス標準ターゲット・アソシエーション」または「リアルタイム監視」ページに、カーネル・モジュールの問題を示すエージェント警告が表示されていることがあります。
AGENT_INST/sysman/logs内のnmxcf.logファイルを調べると、様々な理由でカーネル・モジュールをロードまたは使用できなかったことを示すエラーが表示されていることがあります。
このいずれかの問題が発生した場合、実行時にLinuxカーネル・モジュールのコンパイルまたは挿入に関連する問題があった可能性があります。
次のコマンドを実行すると、監査モジュールが適切にロードされたかどうかを確認できます。
grep -i auditmodule /proc/modules
出力が得られない場合、監査モジュールがロードされず、エージェントによってリアルタイム・ファイル監視は実行されません。
監査モジュール・ファイルが適切に生成されているのに、前述のモジュール・リストに表示されていない場合、手動でモジュールのロードを試行してエラーがないか確認してください。次のコマンドを使用します。{audit module file name}の箇所は、compmod.shから作成された.koファイルの名前全部で置き換えます。
insmod {audit module file name}
このコマンドでエラーが発生しなかった場合は、前述のgrepコマンドを使用して、モジュール・リストを再び確認します。監査モジュールが表示されれば、ファイル監査機能に問題はありません。エージェントは再起動する必要があります。ただし、ファイル監視プロセスで.koファイルの検出に関する問題が残っている可能性があり、ホストを次に再起動してもこの問題は再び発生します。
ファイル監視プロセスに関する問題をデバッグする追加手順の1つは、これを手動で実行する方法です。これを実行するには、次の手順に従います。
エージェントのTMMainプロセスのプロセスIDを取得します。
ps -eaf |grep TMMain
{}内の値を、正しいパス要素または前のコマンドからのプロセスIDに置き換え、次のコマンドを使用して、nmxcfプロセスを実行します。
sudo {agent_home}/core/{agent_version}/bin/nmxcf -e {agent_home}/agent_inst/ -m {agent_home}/agent_inst/sysman/emd/state/fetchlet_state/CCCDataFetchlet -w {process id of TMMAIN}
nmxcfプロセスをこの方法で実行しても、エージェントの再起動時に再開されないため、長期的にはこの方法は機能しませんが、プロセスを開始できない理由に関して問題をデバッグしようとする上で役立ちます。
モジュールがまだロードされず、この問題についてOracleサポートに連絡する場合は、必ず次の情報をサポート・チケットとともに提供してください。
コマンドの出力: uname -a
コマンドの出力: grep –i auditmodule /proc/modules
コマンドの出力: rpm –q –a |grep –i kernel-devel
compmod.shを実行した/opt/fileauditmoduleディレクトリからのmake.logファイルとbuild.logファイル(独自の.koファイルを作成した場合)
ファイルAGENT_INST/sysman/log/nmxc*.log
nmxcfを手動で開始しようとするときに受け取る任意の警告またはエラー
この情報は、エージェントのリアルタイム・ファイル監視の監査モジュールを環境内に作成できるかどうかをOracleサポートが判断する際に役立ちます。
|
警告: カーネル・モジュールをアンロードするために使用されるLinux OSコマンドrmmodを使用する場合は注意が必要です。nmxcfバイナリの実行中にrmmodを使用する場合、使用中のカーネル・モジュールをアンロードしようとするとカーネル・パニックが発生する可能性があります。どのようなモジュールをアンロードする場合でも、Linuxでrmmodを使用する場合は慎重に作業する必要があります。 |
リアルタイム監視機能は、Windows Server 2003および2008とともにWindows XPをサポートしています。Windowsでのリアルタイム監視モジュールは、アクションに関するすべての情報を収集する際に、オペレーティング・システムの様々な機能に依存しています。その1つは、Windowsイベント・ログから変更を行ったユーザーを取得することです。変更を行ったユーザーを取得するようにWindowsを構成していない場合、エージェントによりこの情報は取得されません。ただしその場合も、変更が行われたこと、およびいつ行われたかは取得されます。
リアルタイム監視と連携するようにイベント・ログを構成するには、次の手順を実行します。
Windowsエクスプローラから、リアルタイム監視ルールにより監視するディレクトリを選択し、右クリックして「プロパティ」を選択します。
「セキュリティ」タブに移動します。
「詳細設定」をクリックします。
「監査」タブを選択します。
「追加」をクリックします。(Microsoft XPでは、「監査エントリ」ウィンドウをダブルクリックします。)
名前「Everyone」を選択し、「OK」をクリックします。また、Configuration Change Consoleルールで特定のユーザーによる変更のみを監視する場合は、特定のユーザーを選択することもできます。ルールでは、ユーザーによっても結果がフィルタされるため、すべてのユーザーの監査を有効にした場合でも、ルールで変更を監視するユーザーのみが取得されます。
「アクセス」ウィンドウで次のオプション(「成功」または「失敗」あるいは両方)を選択します。Windows XPおよびWindows 2003の場合。
ファイルの作成/データの書き込み
フォルダの作成/データの追加
サブフォルダとファイルの削除
削除
Windows 2008およびWindows 7の場合。
ファイルの作成/データの書き込み
フォルダの作成/データの追加
書込み属性
書き込み拡張属性
サブフォルダとファイルの削除
削除
権限の変更
所有権の取得
「OK」をクリックして終了します。
監視対象の他のすべてのディレクトリまたはファイルについて、ステップ1から7を繰り返します。
「スタート」メニューから、「設定」、「コントロール パネル」、「管理ツール」、「ローカル セキュリティ ポリシー」、「ローカル ポリシー」、「監査ポリシー」の順に選択します。次のポリシーをダブルクリックしてオンにします(「成功」または「失敗」あるいは両方)。
アカウント ログオン イベントの監査
ログオン イベントの監査
オブジェクト アクセスの監査
「ローカル セキュリティ設定」画面を閉じます。
「スタート」メニューから、「設定」、「コントロール パネル」、「管理ツール」、「イベント ビューア」の順に選択します。
「システム」ログを選択し、メニュー・バーの「操作」をクリックして「プロパティ」を選択します。
「システム ログのプロパティ」パネルの「全般」タブで、「最大ログ サイズ」を5120KB(5MB)以上に設定し、「必要に応じてイベントを上書きする」を選択します。ログ・サイズは、2分間の報告期間にシステムで生成されるイベント数に依存することに注意してください。ログ・サイズは、それらのイベントを収容できるサイズに設定する必要があります。低い変更率が予測されるため、ファイル・イベントの監視時間を延長する場合は、Windowsの監査ログがイベントの取得に十分な大きさであることを確認する必要があります。
「適用」、「OK」の順にクリックして終了します。
Windows監査が適切に設定されていない場合、Cloud Controlユーザー・インタフェースの「コンプライアンス標準ターゲット・アソシエーション」ページに警告が表示されます。このページは、リアルタイム監視のコンプライアンス標準をターゲットと関連付けたページです。
ホストでログイン・イベントおよびログアウト・イベントが記録されることを確認するには、次の手順を実行します。
ホストからログアウトして、再びそのホストにログインします。
「スタート」から、「設定」、「コントロール パネル」、「管理ツール」、「イベント ビューア」の順に選択します。
「セキュリティ」ログを選択し、「表示」メニューから「フィルタ」を選択します。「イベント ソース」に「Security」を、「カテゴリ」フィールドに「ログオン/ログオフ」を選択します。
「OK」をクリックします。
「イベント ビューア」では、このアクティビティがイベント528として記録されます。
前述のように、監査設定が適切に設定されていない場合、エージェントによりサーバーに警告が送信されます。ただし、これはWindows機能のSUBINACLがインストールされている場合のみ行われます。この機能がホストにインストールされていない場合は、監査設定が正しいかどうかをエージェントが検出できないという警告がサーバーに送信されます。この警告は、コンプライアンス標準ターゲット・アソシエーション・ページに表示されます。
subinaclを含むディレクトリの絶対パスを指定するには、AGENT_INST/sysman/config/nmxc.propertiesファイル内に次のプロパティを設定します。
nmxcf.subinacl_dir=
SubInACLはMicrosoft社のWebサイトからダウンロードできます。
Solarisシステムでのリアルタイム監視には、Solaris Basic Security Model(BSM)の一部であるSolaris監査システムが使用されます。システム管理者はBSM監査を行って、イベントを監視し、ユーザー・アカウントのログインおよびログアウトやファイルの変更を検出することができます。
ルート権限で次のコマンドを実行して、BSM監査が有効になっていることを確認します。
/usr/sbin/auditconfig –getcond
次の出力が表示されます。
audit condition = auditing
出力がこれと異なる場合、別のSolarisリリースの別の方法を介してBSM監査を有効にする必要があることを意味します。
次の各環境に対して、次の手順を使用してBSM監査を有効にすることができます。
BSM監査を有効にするには、ルート権限で次のコマンドを使用します。
/etc/security/bsmconv
BSM監視の設定の詳細は、『Solaris BSM Auditing』マニュアルを参照してください。
監査がサーバーですでに有効になっている場合は、次に詳しく示す構成と監査システム構成が一致することを確認してください。
監視ファイルは、特定のイベントを含むように構成できます。/etc/security/audit_controlファイルは、監査ファイルに含めるイベントを制御します。この項では、構成について要約します。詳細は、Sunの製品オンライン・ドキュメント・サイトを参照してください。
エンティティ・タイプOS FILE(ファイル変更)およびOS USER(ユーザー・ログイン/ログアウト)を監視する場合、ファイル/etc/security/audit_control内のフラグ行を次のように設定する必要があります。
フラグ: +fw、+fc、+fd、+fm、+fr、+lo
この構成により、ファイルの書込み(fw)、ファイルの作成(fc)、ファイルの削除(fd)、ファイル属性の変更(fm)、ファイルの読取り(fr)およびログイン/ログアウト・イベント(lo)の成功/失敗の監査が有効になります。+は、成功したイベントのみを記録するという意味です。
失敗したイベントのロギングも行う場合は、フラグの各イベントの前の+記号を削除します。
|
注意: 既存のホストにBSMをインストールする場合は、そのホストを再起動する必要があります。ユーザーの監査: audit_userファイルは、監査対象のユーザーを制御します。このファイル内の設定は特定のユーザーに対するものであり、すべてのユーザーに適用されるaudit_controlファイル内の設定を上書きします。 監査ログおよびディスク領域: audit_controlファイルは、監査ログの格納場所や監査システムで使用されるディスク領域の最大容量を制御するためのエントリを使用します。ファイル監視の最小要件は、10分間(または構成されている報告間隔)でハード・ドライブに格納されるデータの容量にほぼ相当します。 |
Solaris 11では、監査はデフォルトで有効になっていますが、デフォルトで監視されるのはユーザーのログイン/ログアウトのみです。OSファイルの変更イベントとOSユーザーのログイン/ログアウトの両方の監視については、ルート権限で次のコマンドを実行できます。
/usr/sbin/auditconfig -setflags fw,fd,fc,fm,fr,lo
構成フラグの意味は、最後のセクションで定義されているものと同じです。
|
注意: この構成は、ユーザーがすでにホストにログインしている既存のセッションには影響しないため、既存のセッションをすべて終了してから再度ログインするかマシンをそのまま再起動し、この変更を有効にする必要があります。Solaris 11ではbsmconvコマンドが取り除かれているため、必要な場合、次のコマンドを使用して監査機能を有効にすることができます。
|
Cloud Controlのリアルタイム監視では、監査ログが読み取られるのみであり、ログが削除されることはありません。このため、システムにログ・ファイルがあふれて、追加のイベントのロギングができなくなることがあります。監視の最小要件を保持しながら古い監査イベントを管理および削除するには、次の手順に従います。
監査ポリシーを設定して、すべてのプロセスを一時停止するのではなく、新しいイベントを自動的に削除することができます(削除イベントの件数のみを記録)。これには、次のコマンドを実行します。
# auditconfig -setpolicy cnt
次のコマンドを実行すると、監査デーモンが現在の監査ログ・ファイルを閉じて、新しいログ・ファイルを使用するように強制されます。
/usr/sbin/audit -n
次のコマンドを実行すると、閉じている既存の監査ログ・ファイルがすべて.trashという拡張子の1つのファイルにマージされ、続いてそれらのファイルが削除されます。
/usr/sbin/auditreduce -D trash
前述の手順2と3でコマンドを定期的に実行するためのcronジョブを作成します。これらの2つのコマンドを実行する頻度は、予測されるイベント件数と監査に割り当てられているディスク領域の容量に基づいて調整できます。要件は、audit -sコマンドとauditreduce - Dトラッシュ・コマンドの間の時間が15分間以上あるか、報告期間の2倍(変更された場合)であることのみです。
AIXシステムでのリアルタイム監視では、OSによって提供される基礎となるAIX監査サブシステムを使用します。現在サポートされているバージョンはIBM AIX 5.3および6.1のみです。
AIX 5.3ホストでリアルタイム監視を使用する前に、AIX 5.3 5300-08サービス・パック以降を使用していることを確認してください。このメンテナンス・パッケージはIBMから入手できます。
AIX監査サブシステムを使用すると、管理者は、既存のセキュリティ・ポリシーに対する分析やセキュリティ違反の検出のために、ユーザーのログインやログアウトおよびファイルの変更といったセキュリティ関連の情報を記録できます。
監査の設定では、既存の監査構成ファイルを変更します。監査を設定するには、次の手順に従います。
rootユーザーとしてAIXマシンにログインします。
ターミナル・ウィンドウを開き、ディレクトリを/etc/security/auditに変更します。
viで構成ファイルを開きます。
次のセクションを探して、ここに示す値を更新または追加します。
start: binmode = off streammode = on stream: cmds = /etc/security/audit/cccstream classes: … filewatch = PROC_Create,PROC_Delete,FILE_Open,FILE_Write,FILE_Close,FILE_ Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Fchmod,FILE_Fchown,FS_Chdir,FS_Fchdir,FS_Chroot,FS_Mkdir,FS_Rmdir,FILE_Symlink,FILE_Dupfd,FILE_Mknod,FILE_Utimes users: root = filewatch default = filewatch
|
注意: この場合、defaultはroot以外のすべてのユーザーを意味します。また、構成ファイルの最後の行は空白行にする必要があります。 |
|
注意: 各パラメータ(binmode、streammode,、filewatch、rootおよびdefault)に対しては、前の部分にそれぞれタブを1つ用意する必要があります。監査システムですべての変数が適切に使用されていることを確認するには、audit queryコマンドを使用します。出力にfilewatchプロパティが表示されていることを確認します。 |
変更を保存して、viを終了します。
同じディレクトリ(/etc/security/audit/)で、viでファイルstreamcmdsを開きます。
このファイルのすべてのテキストを消去します。ファイル監視エージェント・モジュール(nmxcfプロセス)が直接の監査リーダーとして確認するため、このファイルのデフォルト構成は必要ありません。このファイルの内容を消去すると、CPU使用率が低減し、監査パフォーマンスが全体的に向上します。
ファイルを保存し、viを終了します。
ターミナル・プロンプトで、次のコマンドを入力してシステム起動時に監査を初期化します。
mkitab "audit:2:once:/usr/sbin/audit start"
プロンプトで、コマンド/usr/sbin/audit shutdownおよび/usr/sbin/audit startを使用して監査を再開するか、ホストを直接再起動して監査を有効にします。
プロンプトで、コマンドaudit queryを使用して、監査システムが使用している構成を表示します。プロパティが正しく設定されており、filewatchに必要な設定が行われていることを確認します。
ここでは、Oracleデータベース内で監査を設定するための手順を説明します。Oracleエンティティ・タイプを使用してOracleデータベースを監視する場合は、イベントが取得される前にこれらの手順を実行する必要があります。
監査を構成する前に、『Oracle Database管理者ガイド』のデータベース使用の監査に関する項を参照してください。このドキュメントでは、Oracleの監査機能の概要および監査構成の基本概念とガイドラインが説明されています。Oracle監査システムの構成や細かいチューニングに関する詳細のすべては含まれないことに注意してください。このドキュメントは、リアルタイム監視ルールを使用したリアルタイム監視が有効になるようにOracle監査システムを構成する基本手順の一例を示したものです。
リアルタイム監視のコンプライアンス標準ルールを作成してOracleインスタンス・ターゲットを監視すると、エージェントによって監査証跡が読み取られて、その監視が実行されます。
Oracleエンティティ・タイプのリアルタイム監視を行う場合は、監査証跡をファイルではなくデータベースに格納する必要があります。設定が正しいかどうかを確認するには、次の手順を実行します。
Cloud Controlで、リアルタイム監視を有効にするOracleデータベース・ターゲットのターゲット・ホームページに移動します。
「管理」メニューから、初期化パラメータを選択します。
sysユーザーとしてデータベースにログインし、SYSDBAとして接続します。
audit_trailパラメータを探して、それがDBに設定されていることを確認します。そうでない場合、Oracleデータベース内でこのパラメータを変更する必要があります。
この変更ではデータベースの再起動が必要です。
Oracle DBAは、SQL plusを介してaudit文およびnoaudit文を使用して、データベースの監査オプションを構成できます。audit文では次の3つのレベルで監査オプションを設定できます。
表48-1 監査オプション表
| レベル | 効果 |
|---|---|
|
文 |
特定のタイプのデータベース・オブジェクトに影響する特定のSQL文または文のグループを監査します。たとえば、AUDIT TABLEは、CREATE TABLE、TRUNCATE TABLE、COMMENT ON TABLEおよびDELETE [FROM] TABLEの各文を監査します。 |
|
権限 |
指定したシステム権限の下で実行されるSQL文を監査します。たとえば、AUDIT CREATE ANY TRIGGERは、CREATE ANY TRIGGERシステム権限を使用して発行された文を監査します。 |
|
オブジェクト |
特定のオブジェクトに対する特定の文を監査します(employee表に対するALTER TABLEなど)。 |
audit文を使用して文や権限の監査オプションを設定するには、DBAにAUDIT SYSTEM権限が割り当てられている必要があります。audit文を使用してオブジェクトの監査オプションを設定するには、DBAが監査対象のオブジェクトを所有しているか、Oracle内でAUDIT ANY権限がDBAに割り当てられている必要があります。権限の割当てについては次の項で説明します。
文や権限の監査オプションを設定するaudit文にはBY句を含めることができ、監査する特定のユーザーまたはアプリケーション・プロキシのリストを指定できます。こうすることで、文と権限の監査オプションの範囲が限定されます。
次に監査文の例をいくつか示します。これらは、データベース内で指定する監査設定の基礎として自由に使用してください。すべての監査設定が完了すると、Oracleデータベース・インスタンスの監視に使用するOracle(SQLトレース)エージェント・モジュールを使用してアプリケーション・ポリシーを作成できるようになります。
文の監査オプション(ユーザー・セッション)
次の文は、BillおよびLoriというユーザーのユーザー・セッションを監査します。
AUDIT SESSION BY scott, lori;
権限の監査オプション
次の文は、DELETE ANY TABLEシステム権限の、成功および失敗したすべての使用を監査します。
AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
オブジェクトの監査オプション
次の文は、ユーザーjwardが所有するdept表に対する、成功したすべてのSELECT文、INSERT文およびDELETE文を監査します。
AUDIT SELECT, INSERT, DELETE ON jward.dept BY ACCESS WHENEVER SUCCESSFUL;
Oracle Audit Monitorの構成例
次のコマンドは、すべての基本文を監査します。それ以外の文は監査しません。
Audit all by access;
次の文は、基本以外のすべての文を監査します。
audit ALTER SEQUENCE, ALTER TABLE, DELETE TABLE, EXECUTE PROCEDURE, GRANT DIRECTORY, GRANT PROCEDURE, GRANT SEQUENCE, GRANT TABLE, GRANT TYPE, INSERT TABLE, LOCK TABLE, UPDATE TABLE by access;
次のコマンドは、文の監査設定を表示します。
SELECT * FROM DBA_STMT_AUDIT_OPTS;
監査構成を指定した後は、Cloud ControlサーバーからOracleデータベース・エンティティ・タイプを使用するリアルタイム監視ルールを作成できます。
この項では、変更管理サーバーのインストールおよび変更管理サーバーとの統合の構成を行う方法、および発生した変更が自動的に認可されたものかどうかを判断する方法を説明します。
Remedy ARS 7.1は、監視の自動リコンシリエーションを行うためにサポートされている変更管理システムです。次の手順では、Remedyの設定方法およびCloud Controlとの統合の構成方法について概説します。
Remedy ARS 7.1をインストールおよびカスタマイズするには、次の手順を実行します。
Remedy ARS 7.1をインストールします。次のコンポーネントがすべてインストールされ、適切にライセンスされていることを確認します。
ARS 7.1.00 Patch 011
Midtier 7.1.00 Patch 011
Flashboard Server 7.0.03
Assignment Engine 7.1
Asset Management 7.0.03*
CMDB 2.1.00 Patch 4
CMDB Extension Loader
Approval Server 7.1
Change Management Server 7.0.03 Patch 008*
Problem Management Server 7.0.03*
Incident Management Server 7.0.0*3
User Client
Administrator Client
これらのパッケージはすべてIT Service Management Packに付属しています。Oracleは、ITSM 7.0.03 Patch 008環境におけるRemedyのカスタマイズのサンプルを提供しています。バージョンが異なる場合、Remedyのバージョン間の違いに対応するためにカスタマイズを調整する必要があることがあります。
RemedyがインストールされているホストにCloud Control EMCLI_Clientをインストールします。この場合、Cloud Controlサーバーとの通信が可能である必要があります。
Enterprise Managerコンソールにログインします。
「設定」を選択し、「プリファレンス」メニューから「コマンドライン・インタフェース」を選択します。
「EM CLIキットをワークステーションにダウンロードします。」をクリックし、jarをRemedyサーバーにダウンロードします。
ページに示された手順に従って、EMCLIクライアントをRemedyサーバーにインストールします。
変更リクエスト管理のコネクタ自己更新パッケージの最新バージョンを取得します。また、Cloud Controlバージョン12cのRemedy ARSカスタマイズのサンプルの最新バージョンも取得します。
これらの定義ファイルには、統合のために環境内で行う必要のあるカスタマイズのガイドラインが示されています。これらのカスタマイズ・ファイルでは、Remedy ARSのフレッシュ・インストールが前提となっています。Remedyの本番インスタンスと統合する際は、これらのカスタマイズがRemedyインスタンスに以前に行われたカスタマイズと互換しているか慎重に確認する必要があります。
ActiveLinks _Customization.def
Forms_Customization.def
Menus_Customization.def
Webservices_Customization.def
これらの定義ファイルを取得するには、Enterprise Manager自己更新ユーザー・インタフェースで、コネクタをエクスポートします。定義ファイルは、このコネクタ・パッケージの内部にあります。
次の手順を実行して、実行中のRemedy環境に4つの定義ファイル(.DEF)をインストールします。
Remedy Administratorツールにログインします。
左側の階層から「Remedy」インスタンスを選択します。
「Tools」メニューから「Import Definitions」を選択し、「From Definition File...」を選択します。
前述のリストから、インポートする定義ファイルを選択します。
「Replace Objects on the Destination Server」というラベルのボックスを選択します。
ドロップダウン・オプション「Replace With New Type」を選択します。
「Import」をクリックします。
このプロセス中にエラーは発生しないはずです。インポートが終わると、インポートの完了を示すメッセージが表示されます。
完了したら、残りのカスタマイズ・ファイルについても同じ手順を実行します。
Webサービスをカスタマイズします。
Remedy Administratorツールにログインします。
「Webservices」を選択し、Webサービス「EMCCC_GetCR」を選択します。右クリックし、「Open」を選択します。
「WSDL」タブを選択します。
一番上の入力で、「WSDL Handler URL」内のmidtier_serverおよびservernameの値を変更します。
中間層がlocalhost上にある場合、http://の直後にlocalhostを入力できます。
中間層でポート80が使用されている場合、ポートを省略できます。それ以外の場合は、サーバー名の後にポートを指定します。
servernameのpublic/の後に、Remedyサーバーの名前を入力します。
「View」をクリックします。
WebサービスにはWebサービスWSDLファイルを表すXMLが表示されます。
エラーが表示される場合は、midtier_serverの名前、ポートまたはservernameを確認してください。また、servernameのドメイン部分を追加または削除してみてください。Remedyの「System」 > 「General」 > 「Serverinfo」 >「Connection Settings」で設定したmidtierパスワードが正しくない可能性がある場合、別の問題が発生することがあります。WSDL XMLが返されていない場合は、必ずこのことも確認してください。
「View」をクリックした後にXMLコンテンツが表示されたら、このウィンドウを閉じて変更を保存します。
WebサービスEMCCC_PublishCSDataおよびEMCCC_UpdateChangeRequestに関して、前述の手順すべてを繰り返します。
アクティブ・リンクをカスタマイズします。
Remedy Administratorツールにログインします。
アクティブ・リンクを選択してから、アクティブ・リンク「EMCCCC_ApprovedCR」を選択します。右クリックし、「Open」を選択します。
「If Action」タブをクリックします。
アクション・リストの最後にある現行アクション「Run Process」をクリックします。
「Command Line」フィールドで、パスをemcli.batに変更して、emcliをインストールしたローカル・ホスト上のパスに一致させます。
自動監視リコンシリエーションに使用されるリクエストを作成するためのユーザーをRemedy内に作成します。
管理ユーザーとしてBMC Remedy User Clientにログインします。
User Clientのホームページで「Application Administration Console」をクリックします。
このウィザードのステップ1から4までを行う際は、そのたびに「Create」をクリックします。
人を追加する場合、「Support Groups」タブでサポート・グループを追加します。
「Support Groups」タブで、「Support Group Functional Roles」サブ・タブを選択します。
機能的役割が「Infrastructure Change Management」のサポート・グループを追加します。これを行わない場合、「Infrastructure Change Manager」フィールドにサポート・グループの値がないために、変更リクエストを作成できなくなります。
AR System Administratorコンソールに移動します。
左のサイド・バーで「Application」、「Users/Groups/Roles」、「Select Users」の順に選択します。
これにより、ユーザー検索ページがロードされます。右上の「Search」をクリックします。
前述の手順で新規に作成したユーザーをダブルクリックして、ユーザー・フォームを表示します。
「Group List」フィールドの隣の下矢印をクリックし、「Infrastructure Change Master」を選択します。
前の手順を繰り返し、次のグループもこのユーザーに追加します。
Infrastructure Change Submit
Infrastructure Change User
Infrastructure Change Viewer
ウィンドウの右上隅にある「Save」ボタンをクリックして、このユーザーに対する変更を保存します。
Cloud Controlにコネクタを追加するには、次の手順を実行します。
変更管理コネクタをCloud Controlに追加します。
コネクタの作成権限を持つ管理ユーザーとしてEnterprise Managerにログインします。
「設定」メニューで、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。
「アクション」をクリックし、「管理」を選択します。
「追加」をクリックします。
名前(self update swlibなど)を指定します。
swlibファイルを格納するCloud Controlサーバー上の場所を指定します。これはどこでもかまいませんが、Cloud Controlユーザーがアクセスできるパスである必要があります。ここには絶対パス全部を入力する必要があります。
このプロセスの完了には数分かかります。
コネクタ自己更新パッケージ・ファイルを見つけます。
コネクタjarは、自己更新コンソールを使用してCloud ControlストアからEM@Customerにダウンロードできます。また、自己更新のエクスポート機能を使用して、任意のローカル・ディレクトリにエクスポートできます。
emcli import_update -file=<full path>/connector.zip –omslocalを実行します(connector.zipは自己更新パッケージの名前の一例です)。
前の手順でエラーが発生した場合は、emcliを実行したユーザーにこのディレクトリおよびファイルへのアクセス権限があることを確認してください。また、-fileスイッチに絶対パスを使用していることを確認してください。
成功すると、次のメッセージが表示されます。
操作は正常に完了しました。更新はCloud Controlにアップロードされました。この更新を管理するには、自己更新ホームを使用してください。
Enterprise Managerコンソールにログインします。
「設定」メニューで、「拡張性」、「自己更新」の順に選択します。
「管理コネクタ」タイプを見つけて、このエントリの「ダウンロードされた更新」の下にあるリンク「1」をクリックします。
表からコネクタを選択し、「適用」をクリックします。
変更管理コネクタ・インスタンスを作成します。
Enterprise Managerコンソールにログインします。
「設定」メニューで、「拡張性」、「管理コネクタ」の順に選択します。
「コネクタの作成」の後のドロップダウンから「Remedy Change Management Connector」を選択し、「実行」をクリックします。
コネクタの名前と説明を入力します。この名前は、リアルタイム監視コンプライアンス標準ルールの作成でコネクタを選択する際に使用されます。
管理コネクタ・リストのページに戻った後、新しく追加した行を選択し、「構成」をクリックします。
「Webサービス・エンドポイント」ラベルで、[servername]および[port]を、RemedyインスタンスのWebサービスと一致するように変更します。ここには、先のWebサービスの手順で構成した値と同様の値を入力します。
コネクタ統合に使用するRemedyユーザー名およびパスワードを入力します。
ロケール(enなど)を入力します。
UTCからのRemedyサーバーのタイムゾーン・オフセット(-08:00など)を入力します。
テストとして使用する変更IDを入力します。これは、Cloud ControlとRemedyの間の接続のテストに使用される、Remedyに存在する有効な変更リクエストIDである必要があります。
自動リコンシリエーション機能を使用するようにRemedyをカスタマイズしてCloud Controlコネクタを構成した後は、自動リコンシリエーションを使用するように構成したリアルタイム監視ルールを作成する必要があります。次の手順を実行します。
リアルタイム監視ルールを作成します。
リアルタイム監視ルールを作成するための標準の手順を実行します。
設定ページで「変更リクエスト管理システムを使用して監視を自動認証」を選択します。これにより、検出されたリアルタイム監視のリコンシエーションに対してRemedyによるこの変更リクエストが使用されるように、Cloud Controlが構成されます。
ドロップダウンからコネクタを選択します。
認可済監視チェック・ボックスをクリックして、変更リクエストに注釈を付けます。
この後、引き続きルールを保存します。このリアルタイム監視ルールは、他のリアルタイム監視ルールと同様に使用できます。自動リコンシリエーションを使用したルールを持つ1つ以上のリアルタイム監視標準がターゲットに関連付けられるまで、新しい変更管理サーバーとの統合は開始されません。コンプライアンス標準を作成して、このルールをコンプライアンス標準に追加し、このコンプライアンス標準を1つ以上のターゲットに関連付けます。
ルールの構成の詳細は、コンプライアンス管理に関する項を参照してください。
統合が設定され、リアルタイム監視ルールが作成されたので、RemedyユーザーはRemedyインタフェースで変更リクエストを作成できるようになります。これらの変更リクエストは発生した監視と比較されて、これらの監視が変更リクエストにより認可されたアクションに対応しているかどうかが自動的に判断されます。
この関係付けを行うには、変更リクエスト・ファイラによって、変更リクエスト・フォームに追加された新規のフィールドに入力する必要があります。すべてのフィールドが必須というわけではありません。関係付けは、変更リクエストに存在するフィールドに対してのみ行われます。
たとえば、Oracle Enterprise Managerの「統合」タブの変更リクエスト・フォームに次のフィールドが追加されたとします。
コネクタ: Cloud Controlと統合するためにこの変更リクエストで使用するCloud Controlコネクタを選択します。
ホスト名: この変更リクエストに対応するホスト名。この変更リクエストで誰かが変更する必要があることが指定されているホストです。このフィールドの値が空の場合、すべてのホストがこの変更リクエストに関係付けられます。
ターゲット・ユーザー・リスト: この変更に対応するターゲット・ユーザーのユーザー名。変更を行うためにターゲットにログインするターゲット・ユーザーです。このフィールドの値が空の場合、ターゲット上のすべてのユーザーがこの変更リクエストに関係付けられます。
ターゲット・タイプ: この変更リクエストのターゲット・タイプ。このフィールドの値が空の場合、任意のターゲット・タイプがこの変更リクエストに関係付けられます。
ターゲット: この変更リクエストの特定のターゲット。このフィールドの値が空の場合、任意のターゲット・タイプがこの変更リクエストに関係付けられます。
ファセット: この変更リクエストの特定のファセット。このフィールドの値が空の場合、前述のターゲット・タイプおよびターゲットのすべてのファセットがこの変更リクエストに関係付けられます。
リアルタイム監視ルールにより検出された変更の認可に使用する変更リクエストを作成する際は、変更リクエストの作成に必要な実装を組織が行うことに加え、次の手順を実行します。
変更リクエスト・フォームの「日付」タブで、「スケジュール開始日」と「スケジュール終了日」を入力します。これらは、リクエストのリコンシリエーションが有効になる日付範囲です。この時間外にアクションが行われた場合、そのアクションはリアルタイム監視機能によって未認可としてマークされます。
Oracle Enterprise Managerの「統合」タブを選択します。
ドロップダウン・リストからCloud Controlコネクタを選択します。
オプションで、前述の5つのリコンシリエーション基準の値(「ホスト名」、「ターゲット・ユーザー・リスト」、「ターゲット・タイプ」、「ターゲット」および「ファセット」)を選択します。最後の3つ(「ターゲット・タイプ」、「ターゲット」および「ファセット」)は、Cloud Controlで作成された、ターゲットに関連付けられているコンプライアンス標準に属するリアルタイム監視ルールのコンテンツに基づいて、選択リストとなります。複数の値をカンマで区切って追加できます。
|
注意: このフォームは、Remedyでカスタマイズして外観を変更できます。先にロードされたカスタマイズのサンプル・フォーム要素は、単なる例です。 |
監査可能ステータスをTrueに変更します。これにより、検出されたリアルタイム監視のリコンシエーションに対してCloud Controlでこの変更リクエストを使用できるように、Remedyが構成されます。
変更リクエストを保存します。
ポップアップが表示され、アクティブ・リンクによりコンテンツがCloud Controlに送信されることが通知されます。DOSコマンド・ウィンドウが開かれた後、閉じられます。
リアルタイム監視ルールにより監視されるターゲットまたはファセット(あるいはその両方)を参照する変更リクエストを作成すると、そのルールに対して発生した監視は、一致するすべてのオープン変更リクエストに関係付けられます。
監視がCloud Controlサーバーに到達すると、アクティブであった(スケジュール開始/停止時間に基づいて)、Cloud Controlの「統合」タブの相関基準と一致する、開いている変更リクエストがすべて評価されます。監視の基準と一致する変更リクエストが存在する場合、この監視には「認可済」の監査ステータスのマークが付けられます。ルール構成で「注釈」チェック・ボックスを選択した場合、これらの認可済監視の詳細がRemedy変更リクエストのEnterprise Managerの統合タブの表に取り込まれます。
監視に関係付けできるオープン変更リクエストがない場合、自動リコンシリエーションを使用するようにルールが構成されていれば、この監視は「未認可」監査ステータスに設定されます。この監視が属していた監視バンドルは違反とみなされ、その結果Cloud Controlイベントが作成されます。このイベントは、Cloud Controlイベント・ルールを作成することにより、さらに使用できます。
監視監査ステータスを確認するには、「コンプライアンス」、「リアルタイム監視」、「監視の検索」または参照画面のいずれかを選択して監視の詳細を確認します。適切なロールを持つユーザーは、これらのページから個々の監視の監査ステータスを上書きすることもできます。
未認可の監視が含まれるために違反となっているバンドルはすべて、コンプライアンス結果ページに違反として反映されます。これらの違反によって、コンプライアンス・スコア・スキューは低くなります。これらの違反がクリアされれば、スコアは高くなります。ただし、特定の監視についてのこれらの監査ステータス変更の履歴は保存されます。
リアルタイム監視データにアクセスできるビューは、次のとおりです。
ビュー: mgmt$ccc_all_observations
説明: このビューは、発生したすべての監視を戻します。このビューに対する問合せでは、適切なフィールドに対してフィルタ処理が行われるようにする必要があります。パーティションを最初に利用するフィールドはaction_timeにします。
フィールド:
| フィールド | 説明 |
|---|---|
| OBSERVATION_ID | エージェントにより検出された監視に割り当てられる一意のID |
| BUNDLE_ID | ルール・バンドル設定に基づいてこの監視が属するバンドル |
| TARGET | この監視に対応するターゲット |
| TARGET_TYPE | ターゲットのタイプ |
| ENTITY_TYPE | アクションが行われたエンティティのエンティティ・タイプ |
| ACTION | 監視されたアクション |
| ACTION_TIME | アクションが発生した時刻 |
| USER_TYPE | アクションを実行したユーザーのタイプ(OSユーザー、DBユーザーなど) |
| USER_PERFORMING_ACTION | アクションを実行したユーザーの名前 |
| ORIGINAL_USER_NAME | SU/SUDOアクションの場合、直前のユーザー名(一部のエンティティ・タイプにのみ適用可能) |
| AFFECTED_ENTITY_NAME | このアクションによる影響を受けたエンティティの名前(ファイル名など) |
| AFFECTED_ENTITY_PREVIOUS_NAME | アクションの前のエンティティの名前。たとえば、ファイル名変更アクションの場合、これは古いファイル名になります。 |
| SOURCE_HOST_IP | アクションが別のホストから行われた場合、接続のソースIP(一部のエンティティ・タイプにのみ適用可能) |
| ACTION_PROCESS_ID | アクションを実行したプロセスのPID(一部のエンティティ・タイプにのみ適用可能) |
| ACTION_PROCESS_NAME | アクションを実行したプロセスの名前(一部のエンティティ・タイプにのみ適用可能) |
| ACTION_PARENT_PROCESS_ID | アクションを実行したプロセスの親プロセスのPID(一部のエンティティ・タイプにのみ適用可能) |
| ACTION_PARENT_PROCESS_NAME | アクションを実行したプロセスの親プロセスの名前(一部のエンティティ・タイプにのみ適用可能) |
| ENTITY_PREVIOUS_VALUE | エンティティの前の値(一部のエンティティ・タイプにのみ適用可能) |
| ENTITY_NEW_VALUE | エンティティの新しい値(一部のエンティティ・タイプにのみ適用可能) |
| FILE_ENTITY_PREVIOUS_MD5_HASH | エンティティの前のMD5ハッシュ値(一部のエンティティ・タイプにのみ適用可能) |
| FILE_ENTITY_NEW_MD5_HASH | エンティティの新しいMD5ハッシュ値(一部のエンティティ・タイプにのみ適用可能) |
| AUDIT_STATUS | 監視の現行監査ステータス(unaudited、authorized、unauthorized,など) |
| AUDIT_STATUS_SET_DATE | 最新の監査ステータスが設定された日付 |
| AUDIT_STATUS_SET_BY_USER | 最新の監査ステータスを設定したユーザー |
ビュー: mgmt$ccc_all_obs_bundles
説明: このビューは、すべての監視バンドルのサマリーを戻します。このビューに対する問合せでは、適切なフィールドに対してフィルタ処理が行われるようにする必要があります。パーティションを最初に利用するフィールドはbundle_start_timeにします。
フィールド:
| フィールド | 説明 |
|---|---|
| BUNDLE_ID | ルール・バンドル設定に基づいてこの監視が属するバンドル |
| TARGET | この監視に対応するターゲット |
| TARGET_TYPE | ターゲットのタイプ |
| RULE_NAME | リアルタイム監視コンプライアンス標準ルールの名前 |
| ENTITY_TYPE | アクションが行われたエンティティのエンティティ・タイプ |
| USER_PERFORMING_ACTION | アクションを実行したユーザーの名前 |
| BUNDLE_IN_VIOLATION | バンドルが現在違反しているかどうかを示すブール値。つまり、バンドル内の少なくとも1つの監視が未認可です。Trueは、バンドルが違反していることを示します。 |
| BUNDLE_START_TIME | このバンドル内の最初の監視の日付 |
| BUNDLE_CLOSE_TIME | このバンドルが閉じられた日付 |
| BUNDLE_CLOSE_REASON | このバンドルが閉じられた理由の説明 |
| DISTINCT_OBS_COUNT | このバンドル内の監視数の合計 |
| AUTHORIZED_OBS_COUNT | このバンドル内の現在認可されている監視数 |
| UNAUTHORIZED_OBS_COUNT | このバンドル内の現在未認可の監視数 |
| UNAUTH_CLEARED_OBS_COUNT | このバンドル内の(一時は未認可であったが)現在クリアされている監視数 |
| UNAUDITED_OBS_COUNT | このバンドル内の現在未監査の監視数。これらは、監査ステータスを判別するために手動あるいは変更管理統合による評価が行われていないものです。 |
ビュー: mgmt$ccc_all_violations
説明: このビューは、少なくとも1つの非認証監視が含まれる監視バンドルが原因で発生したリアルタイム監視違反をすべて戻します。
フィールド:
| フィールド | 説明 |
|---|---|
| ROOT_CS_ID | ルート・コンプライアンス標準GUID。これは、違反コンテキストの内部表現に使用されます。 |
| RQS_ID | ランタイム・コンプライアンス標準GUID。これは、違反コンテキストの内部表現に使用されます。 |
| RULE_ID | ルールGUID。違反のあるルールの内部ID。 |
| TARGET_ID | ターゲットGUID。違反のあるターゲットの内部ID。 |
| ROOT_TARGET_ID | ルート・ターゲットGUID。ターゲット階層の内部ID。 |
| RULE_TYPE | ルールのタイプ(リポジトリ、Weblogic Server署名、リアルタイム監視) |
| SEVERITY | ルールの重大度レベル(情報、警告、クリティカル) |
| BUNDLE_ID | 違反のある監視バンドルの内部ID。この監視バンドルには、1つ以上の非認証監視が含まれます。 |
| BUNDLE_START_TIME | 監視バンドルが開始された時刻 |
| BUNDLE_CLOSE_TIME | 監視バンドルが閉じられた時刻 |
| TARGET_TYPE | 監視バンドルおよびこのバンドル内のすべての監視のターゲット・タイプ。 |
| ENTITY_TYPE | 監視バンドルおよびこのバンドル内のすべての監視のエンティティ・タイプ。 |
| USER_NAME | このバンドル内のアクションを実行したユーザー名 |
| AUTHORIZED_OBS_COUNT | この開発に関わる監視バンドル内の認証済監視の数。 |
| UNAUTHORIZED_OBS_COUNT | この開発に関わる監視バンドル内の非認証監視の数。 |
| UNAUDITED_OBS_COUNT | この開発に関わる監視バンドル内の非監査監視の数。 |
| RULE_NAME | この違反があるルール名。 |
| COMPLIANCE_STANDARD_NAME | この違反があるコンプライアンス標準。 |
| TARGET | この違反があるターゲット名。 |
ビュー: mgmt$compliant_targets
説明: このビューは、すべてのターゲットのすべての評価および違反の詳細を戻します。これは、ターゲットの「コンプライアンス・サマリー」ダッシュボード・リージョンに表示されるものと同じデータです。
フィールド:
| フィールド | 説明 |
|---|---|
| TARGET_ID | ターゲットの内部表現 |
| TARGET_NAME | ターゲットの名前 |
| TARGET_TYPE | ターゲットのターゲット・タイプ |
| TARTGET_TYPE_INAME | ターゲット・タイプの内部表現 |
| CRIT_EVALS | クリティカル・レベルの評価の数 |
| WARN_EVALS | 警告レベルの評価の数 |
| COMPLIANT_EVALS | コンプライアンス評価の数 |
| CRIT_VIOLATIONS | クリティカル・レベルの違反の数 |
| WARN_VIOLATIONS | 警告レベルの違反の数 |
| MWARN_VIOLATIONS | マイナー警告レベルの違反の数 |
| COMPLIANCE_SCORE | ターゲットの現在のコンプライアンス・スコア |
ビュー: mgmt$compliance_summary
説明: このビューは、コンプライアンス標準およびフレームワークのすべての評価および違反の詳細を戻します。これは、標準およびフレームワークの「コンプライアンス・サマリー」ダッシュボード・リージョンに表示されるものと同じデータです。
フィールド:
| フィールド | 説明 |
|---|---|
| ELEMENT_NAME | コンプライアンス標準またはコンプライアンス・フレームワークの名前を表示します。 |
| ELEMENT_ID | コンプライアンス標準またはコンプライアンス・フレームワークの内部ID |
| FRAMEWORK_ID | コンプライアンス・フレームワークの内部ID |
| CRIT_EVALS | クリティカル・レベルの評価の数 |
| WARN_EVALS | 警告レベルの評価の数 |
| COMPLIANT_EVALS | コンプライアンス評価の数 |
| CRIT_VIOLATIONS | クリティカル・レベルの違反の数 |
| WARN_VIOLATIONS | 警告レベルの違反の数 |
| MWARN_VIOLATIONS | マイナー警告レベルの違反の数 |
| COMPLIANCE_SCORE | 標準またはフレームワークの現在のコンプライアンス・スコア |
| NON_COMPLIANT_SCORE | 標準またはフレームワークの現在の非コンプライアンス・スコア |
| ELEMENT_TYPE | 要素のタイプ(1=コンプライアンス標準、4=コンプライアンス・フレームワーク) |
| AUTHOR | 標準またはフレームワークの作成者 |
| VERSION | 標準またはフレームワークのバージョン |
| ELEMENT_INAME | 標準またはフレームワークの内部表現 |
ビュー: mgmt$compliance_trend
説明: このビューは、コンプライアンス・フレームワークおよびコンプライアンス標準の過去31日間のコンプライアンス傾向情報を戻します。これは、標準およびフレームワークの「コンプライアンス・サマリー」ダッシュボード傾向リージョンに表示されるものと同じデータです。
フィールド:
| フィールド | 説明 |
|---|---|
| ELEMENT_ID | 標準またはフレームワークの内部ID表現 |
| FRAMEWORK_ID | コンプライアンス・フレームワークの内部ID表現 |
| ELEMENT_NAME | コンプライアンス標準またはコンプライアンス・フレームワークの名前を表示します。 |
| ELEMENT_INAME | 標準またはフレームワークの内部表現 |
| AVG_COMPLIANCE_SCORE | 過去31日間の平均コンプライアンス・スコア |
| DAILY_AVG_VIOLATIONS | 過去31日間の1日当たりの違反の平均数 |
| SNAPSHOT_TS | スナップショットのタイムスタンプ |
| TOTAL_EVALS | 過去31日間の合計評価 |
| ELEMENT_TYPE | 要素のタイプ(1=コンプライアンス標準、4=コンプライアンス・フレームワーク) |
リアルタイム監視機能では、パーティション化およびデータ保存構成が使用されます。
各表とそのデフォルトの保存期間を次に示します。保存期間を変更する場合は、各種機能にわたってデータが整合するように、リアルタイム監視に関連するすべての表を同じ値に変更する必要があります。
|
注意: データ保存値の変更の詳細は、『Oracle Enterprise Manager管理』の管理リポジトリのメンテナンスおよびトラブルシューティングに関する章を参照してください。 |
| 表名 | デフォルトの保存期間 | 説明 |
|---|---|---|
| EM_CCC_WATCHDOG_ALERTS | 366日 | 該当する監視がアクティブではなかったときにエージェントが通知した警告が格納されています。 |
| EM_CCC_HISTORY_JOBEXEC | 366日 | リアルタイム監視機能の一部として実行されるすべてのEnterprise Managerジョブの履歴が格納されています。 |
| EM_CCC_OBSERVATION | 366日 | ユーザー・アクションの個別の監視内容が格納されています(各ファイルの変更、ログイン/ログアウト、プロセスの開始/停止、各データベース・オブジェクトの変更など)。 |
| EM_CCC_OBSGROUP | 366日 | リアルタイム監視ルールのユーザー・インタフェースで設定したバンドル設定に基づいて、単一の監視が1つのバンドルにどのように関連しているかを示す情報が格納されています。 |
| EM_CCC_OBS_GROUP_MAP | 366日 | 単一の各監視バンドルとターゲット、ルール、および該当する監視アクションで監視していた標準の間の関係が格納されています。 |
| EM_CCC_HISTORY_OBS_STATUS | 366日 | 監視ごとの監査ステータス(非監査、未認可、認可)の状態変化に関する履歴が格納されています。 |
| EM_CCC_HA_OBS | 366日 | 1時間ごとの監視数の分析に関する要約、およびレポートされるその他の属性が格納されています。 |
| EM_CCC_HA_OBSGROUP | 366日 | 1時間ごとの監視バンドル数の分析に関する要約、およびレポートされるその他の属性が格納されています。 |
| EM_CCC_FILEOBS_DIFF | 366日 | OSファイル・ベースの監視における以前のファイル比較内容が格納されています。 |
| EM_CCC_AUTHOBS_CR_MAP | 366日 | この表には、監視を認可するのに使用された変更管理リクエスト・システムの変更リクエスト間のマッピングが格納されています。 |
| EM_CCC_CMPUBACTION | 366 | コネクタを使用して、EMサーバーから統合変更管理サーバーにデータを公開するためのリクエストが格納されています。 |
| EM_CCC_CMPUBACTION_DETAIL | 366 | コネクタを使用して、EMサーバーから統合変更管理サーバーにデータを公開するためのリクエストに関する追加の詳細が格納されています。 |
次の表に、リアルタイム監視がサポートされる様々なプラットフォームを示します。すべての表で、Xは、リストされているアクションがサポートされることを表し、NSは、サポートされない(not supported)ことを表します。
この時点では、次のオペレーティング・システムのプラットフォームの組合せはサポートされていません。
Microsoft Windows -- IA64
任意のLinux -- IA64、PA-RISC、POWER
次の表に、OSユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
表48-2 OSユーザーの監視
| 監視するアクション | Oracle/Redhat Linux | Windows | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1およびR2) | ||||||
| X86 32ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | |
|
Telnetログイン(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
Telnetログアウト(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
Telnetログイン(失敗) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSHログイン(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSHログアウト(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSHログイン(失敗) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
コンソール・ログイン(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
コンソール・ログアウト(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
コンソール・ログイン(失敗) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTPログイン(成功) |
NS |
NS |
NS |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
FTPログアウト(成功) |
NS |
NS |
NS |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
FTPログイン(失敗) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUログイン(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUログアウト(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUログイン(失敗) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO(成功) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO(失敗) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDPログイン(成功) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
RDPログアウト(成功) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
RDPログイン(失敗) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
表48-3 OSユーザーの監視
| 監視するアクション | SUSE Linux | Solaris | AIX | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| V10 | V11 | V9 | V10 | V11 | V 5.3 | V 6.1 | |||||
| X86 32ビット | X86 32ビット | X86 64ビット | X86 64ビット | Sparc | X86 64ビット | Sparc | X86 64 | Sparc | 「POWER」 | 「POWER」 | |
|
Telnetログイン(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Telnetログアウト(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Telnetログイン(失敗) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSHログイン(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSHログアウト(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSHログイン(失敗) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
コンソール・ログイン(成功) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
コンソール・ログアウト(成功) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
コンソール・ログイン(失敗) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
FTPログイン(成功) |
X |
NS |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTPログアウト(成功) |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTPログイン(失敗) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SUログイン(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SUログアウト(成功) |
NS |
X |
X |
NS |
NS |
NS |
NS |
X |
X |
NS |
NS |
|
SUログイン(失敗) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SUDO(成功) |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO(失敗) |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDPログイン(成功) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDPログアウト(成功) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDPログイン(失敗) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
次の表に、OSユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
表48-4 OSプロセスの監視
| 監視するアクション | Oracle/Redhat Linux | Windows | Solaris | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1およびR2) | V9 | V10 | V11 | |||||||||
| X86 32ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 64ビット | Sparc | X86 64ビット | Sparc | X86 64ビット | Sparc | |
|
プロセス開始(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
プロセス停止(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
Linux v5では、監視を行う方法は2つあります。次に示す監視対象アクションの中には、一方の方法でのみ監視できるものがあります。2つの方法は、ロード可能なカーネル・モジュールを使用することです。この方法によってのみ検出可能なアクションは、"(KO)"という注釈で示します。別のオプションはロード可能なカーネル・モジュールを使用しないことで、Linuxに組み込まれている監査方法を使用することになります。この方法でのみ監視可能なアクションは、"(非KO)"という注釈で示します。チェックマーク以外の注釈のないアクションは、いずれの方法でも監視できます。
Microsoft Windowsオペレーティング・システムのごみ箱からファイルをリストアする場合、この機能はオペレーティング・システムからは使用できないため、変更を加えたユーザーを特定することはできません。
Linuxオペレーティング・システムで、Oracleカーネル監査モジュール・メソッドではなくauditd監視メソッドを使用している場合、ディレクトリ作成操作はファイル作成操作としてレポートされます。さらに、ファイル作成アクティビティは、作成ではなくファイル変更としてレポートされます。これらは、監視でauditdメソッドを使用する際の制限事項です。LinuxでのOSファイル監視にOracleカーネル監査モジュールの手法を使用する場合、これらの制限事項は適用されません。
Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
表48-6 OSファイルの監視
| 監視するアクション | Linux | Windows | Solaris | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1およびR2) | V9 | V10 | V11 | |||||||||
| X86 32ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 64ビット | Sparc | X86 64ビット | Sparc | X86 64ビット | Sparc | |
|
ファイルの読込み(成功) |
X |
X (KO) |
X (KO) |
X (KO) |
X (KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイル削除(成功) |
X |
X |
X |
X (KO) |
X (KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイルの名前変更(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイル作成(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイル・コンテンツの変更(成功) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
コンテンツ変更なしのファイル変更 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイル変更(失敗) |
NS |
X (非KO) |
NS |
X (非KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
ファイル権限の変更(成功) |
NS |
X (非KO) |
X (非KO) |
X (KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル所有権の変更(成功) |
NS |
X (非KO) |
X (非KO) |
X (KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル・コンテンツの変更(成功)アーカイブ・ファイル |
NS |
X (非KO) |
X (非KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
ファイルの読込み(失敗) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル削除(失敗) |
NS |
X (非KO) |
X (非KO) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイルの名前変更(失敗) |
NS |
X (非KO) |
X (非KO) |
X (非KO) |
X (非KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル作成(失敗) |
NS |
X (非KO) |
X (非KO) |
X (非KO) |
X (非KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル権限の変更(失敗) |
NS |
X (非KO) |
X (非KO) |
NS |
X (非KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
ファイル所有権の変更(失敗) |
NS |
X (非KO) |
X (非KO) |
NS |
X (非KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
表48-7 OSファイルの監視(続き)
| 監視するアクション | SUSE Linux | AIX | |||
|---|---|---|---|---|---|
| V10 | V11 | V5.3 | V6.1 | ||
| X86 32ビット | X86 32ビット | X86 64ビット | 「POWER」 | 「POWER」 | |
|
ファイルの読込み(成功) |
X |
X (KO) |
X (KO) |
X |
X |
|
ファイル削除(成功) |
X |
X (KO) |
X (KO) |
X |
X |
|
ファイルの名前変更(成功) |
X |
X |
X |
X |
X |
|
ファイル作成(成功) |
X |
X |
X |
X |
X |
|
ファイル・コンテンツの変更(成功) |
X |
X |
X |
X |
X |
|
コンテンツ変更なしのファイル変更(成功) |
X |
X |
X |
X |
X |
|
ファイル変更(失敗) |
NS |
NS |
NS |
X |
X |
|
ファイル権限の変更(成功) |
X |
X (KO) |
X |
X |
X |
|
ファイル所有権の変更(成功) |
X |
X (KO) |
X |
X |
X |
|
ファイル・コンテンツの変更(成功)アーカイブ・ファイル |
X |
X |
X |
X |
X |
|
ファイルの読込み(失敗) |
NS |
NS |
NS |
X |
X |
|
ファイル削除(失敗) |
NS |
NS |
NS |
X |
X |
|
ファイルの名前変更(失敗) |
NS |
X (非KO) |
X (非KO) |
X |
X |
|
ファイル作成(失敗) |
NS |
NS |
X (非KO) |
X |
X |
|
ファイル権限の変更(失敗) |
NS |
X (非KO) |
X (非KO) |
X |
X |
|
ファイル所有権の変更(失敗) |
NS |
X (非KO) |
X (非KO) |
X |
X |
次の表に、OS Windowsレジストリの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
表48-8 OS Windowsレジストリの監視
| 監視するアクション | Windows | |||||
|---|---|---|---|---|---|---|
| XP | 2003 Server | 2008 Server (R1およびR2) | ||||
| X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | X86 32ビット | X86 64ビット | |
|
キーの作成(成功) |
X |
NS |
X |
X |
X |
X |
|
キーの削除(成功) |
X |
NS |
X |
X |
X |
X |
|
値の作成(成功) |
X |
NS |
X |
X |
X |
X |
|
値の変更(成功) |
X |
NS |
X |
X |
X |
X |
|
値の削除(成功) |
X |
NS |
X |
X |
X |
X |
|
キーの作成(失敗) |
X |
NS |
X |
NS |
NS |
NS |
|
値の作成(失敗) |
X |
NS |
X |
NS |
NS |
NS |
|
値の変更(失敗) |
X |
NS |
X |
NS |
NS |
NS |
|
値の削除(失敗) |
X |
NS |
X |
X |
X |
X |
次の表に、OS Windows Active Directoryユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、OS Windows Active Directoryコンピュータの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、OS Windows Active Directoryグループの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Database表の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
表48-12 Oracle Database表の監視
| 監視するアクション | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
挿入(成功) |
X |
X |
X |
X |
|
選択(成功) |
X |
X |
X |
X |
|
更新(成功) |
X |
X |
X |
X |
|
削除(成功) |
X |
X |
X |
X |
|
作成(成功) |
X |
X |
X |
X |
|
削除(成功) |
X |
X |
X |
X |
|
切捨て(成功) |
X |
X |
X |
X |
|
変更(成功) |
X |
X |
X |
X |
|
コメント(成功) |
X |
X |
X |
X |
|
名前変更(成功) |
X |
X |
X |
X |
|
ロック(成功) |
X |
X |
X |
X |
|
付与(成功) |
X |
X |
X |
X |
|
取消し(成功) |
X |
X |
X |
X |
|
監査(成功) |
X |
X |
X |
X |
|
NOAUDIT使用 |
X |
X |
X |
X |
|
フラッシュバック(成功) |
X |
X |
X |
|
次の表に、Oracle Databaseビューの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseマテリアライズド・ビューの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Database索引の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Database順序の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseプロシージャの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseファンクションの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseパッケージの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseライブラリの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseトリガーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Database表領域の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseクラスタの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseリンクの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseディメンションの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseプロファイルの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseパブリック・リンクの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseパブリック・シノニムの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseシノニムの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseタイプの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
次の表に、Oracle Databaseロールの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。
