監視と検知が可能にする迅速なインシデント対応ネットワーク運用におけるセキュリティ(4/4 ページ)

» 2006年03月17日 11時30分 公開
[佐藤功陛,ITmedia]
前のページへ 1|2|3|4       

 まず、イベントの重要度やセベリティ(緊急度)に基づくフィルタリングを行う。重要度が低く、緊急の対応が不要なものはフィルタをかけて通知されないようする。

 次に、イベントの内容によるフィルタを適用する。検知されたイベントが誤検知である場合もあるため、運用されている環境に応じて、ソースとなる機器に基づいてフィルタリングを行う。

 発生頻度の低いイベントが発生した場合にも、その都度フィルタを設定し、重要かつ危急な対応が必要なものだけが通知されるようにメンテナンスを行う。一方で、重要なイベントがフィルタリングされている可能性もあるため、定期的に全イベントの見直し、フィルタの確認を行うことも重要だ。

 なお、フィルタリングの重要性は認識されていても、通知されたイベント内容と対になる「対応マニュアル」が用意されていない場合が多い。しかし、マニュアルが存在せず、「データベースのトラブルはAさん、ファイアウォールのトラブルはBさんしか対応できない」といった極端に属人性が高い状況では、初動対応が遅くなるばかりでなく、担当者が長期休暇や出張もできない状況になってしまう。したがって最低限、過去に発生したトラブルの対処方法や問題の切り分け方法をまとめたマニュアルや、対応履歴(運用記録)を用意するべきだろう。

 今回の記事では「監視」と「検知」についていくつかポイントを紹介したが、検知後の「判断」「対応」も非常に重要である。事前にフローを作成することの重要性については言及したが、フローは、運用を行っている組織の実態と方針(ポリシー)に基づいて作成しなければならない。例えば、

  1. 発生事象の重要度
  2. エスカレーションをする相手
  3. 事象発生からエスカレーションするまでの時間

は連動している必要がある(図3)。

レベル 概要
明らかに事業に支障が出る障害 致命的なアプリケーションの不具合が発生した
二重化されたデバイスのフェイルオーバーに障害が発生した
一部の事業や業務に支障が出る障害 二重化されたデバイスの片系に障害が発生した
SLAに関連しないアプリケーションの不具合が生じた
限定的で、事業に具体的な支障が発生しない障害 検証環境のハードウェア障害が発生した
障害レベルの分類
エスカレーション先 連絡者 レベル高 レベル中 レベル低
スーパーバイザー 担当者より連絡 10分 2時間 8時間
マネージャ スーパーバイザーより連絡 15分 4時間
部長 マネージャより連絡 15分
関連部署 スーパーバイザーより連絡 15分
サポートベンダー 担当者より必要に応じて連絡
エスカレーション先および目標時間

 また、人によって重要度の分類基準が異なっている場合もあるので、最低限、事前にチーム内で実例を交えて重要度分類の基準についてコンセンサスを取っておくようにする。そして可能であれば、本番を想定した訓練を実施するとよりだろう。

 ここまで紹介した内容が、実際に運用を行っている方の役に立てば何よりである。運用担当者の中には、「何をいまさら当たり前のことを言っているんだ」と思われる方もおられると思うが、当たり前のことを長期にわたり継続して行うには、それなりの労力と創意工夫が必要である。運用において最も重要なことは、当たり前のことを継続して行うことに尽きるという点を強調し、まとめとしたい。

■佐藤功陛

 インターネット セキュリティ システムズ マネージドセキュリティサービス部部長代理。マネージドセキュリティサービス(MSS)におけるセキュリティオペレーションセンター(SOC)およびインフラストラクチャの責任者の立場から、大規模な運用管理・監視におけるサーバ・ネットワークの設計、構築、運用に深い造詣と経験を持つ。2002年同社入社以前には、大規模データセンターの立上げや企業買収によるインフラ統合プロジェクトに技術リーダーとして携わった。

前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ