リアルタイム監視の調査
前に説明したとおり、監視は、ホストに表示されたアクションまたはリアルタイム・モニタリング・ルールでモニター対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。
監視は多くの監査ステータスの1つを持つことができます。基本監査ステータスである非監査は、監視が検出されたが、このアクションが良好であるか不良であるかは示されていないことを意味します。認証済ステータスは、監視に対してなんらかの確認が行われており、これは発生が予期される(良好な変更であった)ものとして処理する必要があることを意味します。非認証ステータスは、この監視が確認されており、ポリシーに違反することが判明したことを意味します。この結果、修正、ポリシーの変更、または補正制御が行われる場合があります。監視の監査ステータスをルールによって自動的に設定することにより、ルールによってトリガーされるすべての監視をデフォルトの監査ステータスにすることができます。また、後述するUIレポートを介してステータスを手動で設定することもできます。最も高度な機能には、アクションの実行が想定されていたかどうかを監視ごとに自動的に確認するためにCloud Controlコネクタを介して変更管理リクエスト・サーバーと統合する機能が含まれます。
次の各項で、リアルタイム・モニタリングの監視の詳細を示します。
監視の表示
使用環境内で発生したリアルタイム・モニタリングの監視を確認する方法は主に4通りあります。
最初の3つの監視画面は、「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択することによってアクセスできます。このページでは、3つのレポートのうちどれを参照するかを選択でき、リアルタイム・モニタリング・ルール構成に関連する管理エージェントの警告も表示されます。これらの警告は、管理エージェントからレポートされ、Cloud Controlサーバーへの監視の配信に影響を及ぼす可能性があります。予期される監視が欠落している場合は、これらの警告を確認し、それらの原因である構成問題に対処します。
システム別の監視の表示
監視が発生したときに、その監視を自動的に認証済または非認証としてマークできます。これは、調査する必要のある重要な監視を見つける1つの方法を提供します。ただし、監視を変更管理サーバーと調整するようにルールが構成されていない場合、属性検索のみで重要な監視を見つけることは困難な可能性があります。ビジネス・アプリケーション(汎用システム)別に監視を表示し、監視の詳細にドリルダウンできる機能により、監視の監査ステータスとは関係なく、調査する必要のある問題が発生している可能性のある場所を特定できます。
通常、ITマネージャと部門所有者は、ビジネス・アプリケーションで好ましくない構成の変化が発生したかどうかを識別する必要があります。監視をシステム別に表示することにより、どの変更がビジネス・アプリケーションに影響を与えているかを容易に確認できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。
これは、1つ以上のビジネス・アプリケーションを選択し、監視の相対数を参照できることから始まります。ITマネージャおよびコンプライアンス監査者がターゲットの使用目的を把握していない可能性があるため、このレポートはビジネス・アプリケーション・レベル(汎用システム)で開始されます。ビジネス・アプリケーションはCloud Controlで汎用システムとしてモデル化されます。
より熟達したユーザーであれば、これが作業対象のビジネス・アプリケーションである場合、このビジネス・アプリケーション・レベルで開始してもかまいません。
システム別に監視を表示するには、次のステップに従います。
コンプライアンス・フレームワーク別の監視の表示
コンプライアンス標準の構造に関係する場合の監視を表示する機能は、ITマネージャ、部門オーナー、コンプライアンス・マネージャ、経営者など技術者以外が実行するのが一般的です。
組織が準拠しているITコンプライアンス・フレームワークが反映されている特定のコンプライアンス・フレームワーク・セットを識別できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。
コンプライアンス・フレームワーク別に監視を表示するには、次のステップに従います。
これらの画面で提供されるこのドリルダウン機能により、監視の発生箇所を容易に特定できます。数百のビジネス・アプリケーションにわたって数万のターゲットが存在する環境では、ユーザーが検索条件を正確に把握していないかぎり、表と検索を使用して単純に監視を表示することが重要です。このような大規模な環境では、たとえアクティビティが少ない場合でも、数時間のうちに数千の監視が発生する可能性があります。
検索別の監視の表示
2画面による参照でも、使用環境内でどのような監視が行われたかに関する最適なビューを得られない場合は、監視を検索するための検索機能を使用することもできます。
監視を検索するには、次のステップに従います。
インシデントの詳細の表示
監視は、コンプライアンス基準ルール、ターゲット、およびアクションを実行したユーザーに基づいて論理的にバンドルされます。このバンドルの詳細は、リアルタイム・モニタリング・ルールの作成に関する項を参照してください。
バンドルの1つ以上の監視が認証されない場合、そのバンドルは違反とみなされます。この違反の結果、Cloud Controlインシデント管理でイベントが作成されます。イベント名は、リアルタイム・モニタリング・ルールに定義されているメッセージ・フィールドに基づいて付けられます。インシデント管理UIでこのイベントを表示する場合、ターゲット・タイプ、エンティティ・タイプ、バンドル内の監視の数、監査ステータス別の監視などのバンドルの詳細が複数のフィールドに表示されます。「監査ステータスの更新」リンクをクリックすると、バンドル監視ページに移動できます。
この「監視」ページには、このイベントの監視バンドルに含まれている監視のリストが表示されます。各監視は、認証済/非認証ステータス、ユーザー、時間などの様々な属性でフィルタできます。
コンプライアンス評価時の監視の操作
次の各項では、リアルタイム・モニタリングの監視の監査ステータスを調整する方法や、コンプライアンス結果を評価する上で通知がどのように役立つかについて説明します。
監視の認証済または非認証への手動設定
リアルタイム監視の詳細を表示している場合は常に、監視の監査ステータスを変更できます。ユーザー処理を調査して、アクティビティが異なる監査ステータスになる必要があると判断した場合、監視の監査ステータスを上書きできます。リアルタイム・モニタリング・ルールに基づいて、すべての監視は、事前設定された監査ステータスを持つか、変更リクエスト管理サーバーとの統合によって決定された監査ステータスを持ちます。使用可能な監査ステータスは、次のとおりです。
-
非監査: 監視が良好か不良かを確認する評価が行われていません。
-
認証済: 監視は良好で、実行することが望ましいアクションであったことが確認されました。
-
非認証: 監視は不良で、不要なアクションであったことが確認されました。
-
非認証-クリア済: 監視は不良で、不要なアクションであったことが前に確認されましたが、修正、ポリシー変更または補正制御によって処理されており、現在はクリアされています。
監視の監査ステータスを変更するには、UIページ、監視検索ページ、またはインシデント・マネージャUIを使用した参照によって監視を表示します。監視を選択し、「監査ステータスの更新」をクリックします。ポップアップが表示され、新規監査ステータス、およびステータスの変更理由を説明するコメントを選択できます。監視ごとに監査ステータスのすべての変更の履歴が保持されます。
Cloud Controlインスタンスによって統合用の変更リクエスト管理サーバー・コネクタが使用されている場合、特別な考慮事項があります。
-
非認証の監視を認証済の監視に変更する場合、変更を認証する変更リクエストIDを入力するオプションがあります。この変更リクエストIDは、変更リクエスト管理システムにすでに存在するリクエストと一致する必要があります。コメントも入力できます。変更リクエストIDが提供されると、システムが自動的に認証したかのように、変更リクエストに変更の注釈が付けられます。監視バンドルにインシデントが作成された場合、イベント/インシデントが新しい数の非認証の監視で更新されます。
-
認証済の監視を非認証または未監査の監視に変更する場合、変更リクエストに付加された注釈はロールバックされます。監視バンドルに対してすでにインシデントが発生している場合は、注釈が変更され、インシデント内の非認証の監視の数が更新されます。これがグループ内の最初の非認証の監視である場合は、イベントが作成され、インシデントが発生します。変更に関するコメントを入力できます。
-
監視を手動で認証済に設定して変更リクエストIDを入力し、ルールで変更管理との統合が有効化されている場合、変更リクエストの属性は監視と比較されません。その変更リクエストは、単に監視詳細によって更新されます。
-
変更管理サーバーで注釈をロールバックすると、監視の注釈は実際に削除されるのではなく、ロールバック済としてマークされます。これは、注釈が削除された理由がわからないことなどによってユーザーが混乱するのを防ぐためです。また、後で監視が再び認証済になった場合は、単にロールバック済のマーキングが削除され、注釈が戻されます。
監視が発生した場合のユーザーへの通知
コンプライアンス基準ルールが作成され、そのルールとの変更管理リコンシリエーションを使用しない場合、監視で認証/非認証の自動チェックは実行されません。このルールに、各監視バンドルに対して情報イベントが生成されるように指定できます。この構成方法の詳細は、リアルタイム・モニタリング・ルールの作成に関する項を参照してください。
イベントには注釈が付きます。ユーザーは、インシデント管理コンソールからイベントおよびインシデントを参照できます。単一イベントを参照する場合、その監視バンドルのイベントに関連付けられている監視を参照できるリンクがあります。各監視バンドルには、1つのイベントのみが作成されます。バンドル内の少なくとも1つの監視が認証されないと、そのバンドルは違反とみなされ、イベントが生成されます。
この通知はユーザーによる操作または後続処理を必要としないため、情報として扱われます。後から誰かがこれらの未監査の監視のいずれかを認証済または非認証の監視に変更した場合、未監査の監視に対する新規情報イベントは再配信されません。イベントは、監視バンドルに対して1回のみ配信されます。ただし、いずれかの監視が手動で非認証に設定された場合は、その監視バンドル全体に対して違反が発生します。
バンドル内の少なくとも1つの監視が非認証状態である場合、違反が作成されます。この違反は、インシデント・マネージャ・コンソールでイベントになります。「インシデント・マネージャ」機能を使用して通知を設定します。この詳細は、インシデント・マネージャ・ページで、オンライン・ヘルプの概要に関する章の通知の設定に関する項にある、ルールを使用した通知の設定に関する項のリンクをクリックしてください。