コンフィグレーションコンプライアンス修復タスクとタスクルールの概要

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:5分
  • 修復タスク (RT) を自動的に作成し、修復タスクルールを使用して結果を一括で分析します。タスクを構成するクライテリアを設定すると、テスト結果を手動で修復タスクにアサインする必要がなくなります。

    注:
    コンフィグレーションコンプライアンス の v14.9 以降では、次の用語が変更されました。
    表 : 1. 用語の変更
    v14.9 より前の用語 v14.9 以降の用語
    テスト結果グループ 修復タスク
    グループルール 修復タスクルール
    ポリシー テストグループ

    修復タスクについて

    修復タスクは、修復する一連のテスト結果を表します。テスト結果のグループ化には多くの利点があります。修復ステータスを使用してテスト結果を移動したり、調査中としてマークしたり、保留したり、グループを使用してまとめて解決済みとしてマークしたりすることができます。指定した結果、テクノロジー、リスクスコア、およびテスト結果に関連するその他のデータを使用して、すべての結果を自動的にグループ化する条件を作成できます。テスト結果は複数の修復タスクに属することができるため、1 つの修復タスクに対して積極的に作業を行いながら他のグループを監視するといった柔軟性があります。すべて、柔軟な形で同時に実行することが可能です。たとえば、アサイン別にグループ化して、テクノロジーを含むグループを作成することもできます。

    修復タスクは次のように作成されます。
    • 2 つのオプションのいずれかを使用して、手動でテスト結果をグループに追加します。
      • 手動:エントリーなしで修復タスクを作成します。テスト結果は手動で追加する必要があります。
      • フィルター:修復タスクを作成し、条件を使用してテスト結果をその修復タスクに自動的に追加します。
      注:
      手動で追加されたテスト結果は、修復タスクルールまたは修復タスク条件によって自動的に修復タスクから削除されることはありません。
    • 修復タスクルールを使用して自動的にこのオプションは最も簡単なオプションです。一度構成すると、修復タスクルールによって必要なすべての修復タスクが作成されます。

    修復タスクから、テスト結果のグループをユーザーにアサインしたり、後日まで保留にしたり、[変更要求] の作成に使用したり、使い方は様々です。

    注:

    sn_vulc.remediation_owner ロールを使用すると、自分または自分のアサイン先グループにアサインされたテスト結果や修復タスクを表示および更新できます。モジュールを表示するには、 すべて > コンフィグレーションコンプライアンス > テスト結果 > 自分のオープンなテスト結果、または コンフィグレーションコンプライアンス > 修復タスク > 自分のオープンタスク.

    新しいテスト結果を修復タスクに追加できると判断されると、テスト結果は修復タスクの [テスト結果] 関連リストに含められます。

    修復タスクのステータスを更新すると、関連するテスト結果ではステータスをこの修復タスクに合わせて更新できます。ステータス変更の詳細については、「コンフィグレーションコンプライアンス のステータス」を参照してください。

    修復タスクルールについて

    修復タスクルールを使用すると、テスト結果を自動的にグループ化してアサインする方法を定義できます。テスト結果の [アサイン先グループ] および [テスト] フィールドを基づきテスト結果をグループ化するベースシステムには、デフォルトルールである [アサイン先グループ、テスト (Assignment group, Test)] が含まれています。このルールはデフォルトで無効になっています。テスト結果からアクセス可能な列では、値の他のセットでグループ化できます。キーは最大 6 つまで、条件はいくつでも使用できます。詳細については、「コンフィグレーションコンプライアンス 修復タスクルールの作成または編集」を参照してください。

    重要:
    管理者およびアナリストは、脆弱性マネージャーワークスペースで選択したテスト結果の修復タスクルールを評価できます。この方法は、時間のかかるクラシック UI で修復タスクルールを再適用するよりも効率的です。詳細については、「脆弱性マネージャーワークスペース でレコードの修復プロパティを再評価する」を参照してください。

    たとえば、アサイン先グループまたはテクノロジー、構成アイテム (CI) 別にテスト結果をグループ化できます。会社がより大きなリスクにさらされるテスト結果には、別のルールセットを使用できます。低重大度または低リスクの CI に対して、1 つの修復タスクルールを設定できます。使用可能なフィールドの詳細については、「コンフィグレーションコンプライアンス テスト結果の表示」を参照してください。

    新しいテスト結果がインポート、またはクローズされてから再度オープンされると、そのテスト結果に対して修復タスクルールが評価されます。テスト結果は、クローズ後に再オープンされない限り、1 回しか評価されません。

    修復タスクルールは、CI との照合、リスクスコアの算出、アサインルールの後で評価されます。

    新規または再オープンされたテスト結果ごとに、次の処理が使用されます。
    • 修復タスクルールごとに、テスト結果が条件フィルターと比較されます。
    • ルール条件が一致する各ルールについて、テスト結果のグループキー列からデータがプルされます。このルールでは、テスト結果と同じアサイン先グループにアサインされている、一致するオープン修復タスクがあるかどうかを確認します。

      修復タスクが見つかった場合、テスト結果は [オープン ] ステータスの既存の修復タスクに追加されます。

    • [オープン] ステータスの修復タスクが見つからない場合は、ルールによって修復タスクが作成され、ルールの [ユーザーグループ] または [キー] の値に基づいてアサインされ、そこにテスト結果が配置されます。

    複数のテスト結果ルールを定義して、さまざまな種類の結果をグループ化できます。各結果は修復タスクに配置される前にルール条件と比較されるため、ルールが多すぎるとパフォーマンスに影響を与える可能性があります。

    修復タスクルールが削除されると、そのルールによって作成された未処理のタスクもすべて削除されます。これは、ルールのフォームビューとリストビューの両方に適用されます。

    修復タスクがアサインされたり変更されたりすると、テスト結果が RT と異なるアサイン先グループである場合を除き、[アサイン先グループ] フィールドと [アサイン先] フィールドがロールダウンしてすべてのテスト結果が表示されます。アサインルールについては、「コンフィグレーションコンプライアンス アサインルールの概要」を参照してください。これらのアサインは、次のインポート時にこのグループに対して自動的に使用されます。

    テスト結果と修復タスクの保留数を追跡する

    v14.3 以降では、テスト結果または修復タスクが複数の保留モジュールで保留された回数を追跡します。スケジュール済みジョブである [保留数の設定 (set deferral counts)] は毎日実行され、複数の保留モジュールにリストされているレコードの [保留数] 列で複数回保留されたレコード数が提示されます。