脆弱性対応 CI ルックアップルールの実行後にレコードが重複または孤立しないようにするための手順
CMDB 内の構成アイテム (CI) の一致によって、重複レコードまたは孤立レコードが発生しないようにするための手順を実行します。
脆弱性データのインポートはインスタンスに負荷をかける可能性があり、慎重にルールをビルドしないと、リソースのパフォーマンス問題が発生する可能性があります。CMDB 内で反復して照合を実行するために使用されるロジックでは、処理時間が長くなる可能性があります。ルール内の処理スクリプトを徹底的にテストしてデバッグすることで、プロセスの後半で発生する可能性のある問題を軽減できます。
重複レコードまたは孤立レコードの防止
- テストする CI ルックアップルールに固有の、小さいデータのサブセットを使用します。
- テスト対象を除いて、すべての [CI ルックアップルール] を [非アクティブ] に設定します。
- インポートされた CI を分析し、想定される動作を観測していること、照合が適切に行われていることを確認します。
- 一致した CI のレビュー
- 一致した CI と一致しなかった CI の数を確認します。比率が許容範囲であることを確認します。最初のページを見るだけで済ませないでください。挿入された最初の 1 つである可能性があります。
- 一部の CI を手動で検索します。
- 命名またはフィールドの問題 (特定のドメインの検索など) がないかどうかを確認します。
適切と思われる場合は、一致ルールを追加します。
- 一致しなかった CI のレビュー
- [一致しない CI] テーブルに移動します。
- 構成アイテムクラス別にグループ化します。
- 正しくないと思われるクラス (証明書、ネットワークカード、イメージ) をレビューします。
- なぜ正しい CI と一致しなかったのでしょうか？
- クラスを除外する必要がありますか？
- クラスを関連クラスに昇格させる必要がありますか？
- [廃止] などの CI 状況を確認します。
- テストデータの削除
- CI の照合で正しい動作または予想される動作を観察し始めたら、最初からやり直します。
- テストに使用したデータを削除して最初からやり直します (「テーブルからのデータの削除」セクションを参照)。
- 検出されたアイテム
- 脆弱性一致アイテム
- 修復タスク
- すべての CI 一致ルールを手動で再実行します。
CI ルックアップルールと Qualys の詳細については、KB0750656 の記事を参照してください。
CI ルックアップルールと Rapid7 の詳細については、「KB0818096」を参照してください。
テーブルからのデータの削除
データをインポートしたときに、問題があることに気付くことがあります。開発環境やパフォーマンス環境で何か問題が発生した場合、より良い環境から再クローンできることもありますが、いつもできるとは限りません。
注:
これらのアクションを実行するには、ServiceNow の専門知識が必要です。
テーブルからデータを削除するには、次の 4 つのオプションがあります。
- [テーブル構成] で [すべてのレコードを削除] を使用する。
- [自動フラッシュ] (sys_auto_flush.list) に移動し、新しい [自動フラッシュ] レコードを作成して、[テーブルクリーナー] を設定します。
- バックグラウンドスクリプトを使用して gs.truncateTable を切り捨てます。
truncateTable を使用するには、バックグラウンドスクリプトの [ロールバック用に記録] チェックボックスをオフにする必要があります。オフにしないと、テーブルと関連するカスケードテーブルのコピーが作成され、時間がかかりすぎて多くの場合は失敗します。
注:本番環境では truncateTable を使用しないでください。本番環境や共有環境で大規模な削除を実行する場合は、事前にサポート担当者にご相談ください。