SOCを例としたインシデント対応のポイントネットワーク運用におけるセキュリティ(2/3 ページ)

» 2005年08月26日 16時23分 公開
[徳田敏文、高橋正和,ITmedia]

 エスカレーションフローを作成する場合は、図2のように、「誰が」「どこに」「何分以内に」連絡するかを明確にし、あわせてフロー図を作成しておくと、インシデント発生時に慌てることが少なくなるだろう。フロー図には、「電話」と「メール」、あるいはその両方といった具合に、連絡方法と電話番号やメールアドレスなの連絡先を直接書き込んでおくとよい。

 なお、作成されたエスカレーションフローを常に最新に保つよう、ドキュメント管理を徹底しておくことは言うまでもない。インシデントが発生した際にかけた電話番号が古く、連絡先探しに奔走する間に事態を深刻化させてしまったという笑えない事例も実際に発生している。

連絡元 連絡先
SOC 部門 担当営業 パートナー お客様
運用担当者 チーフ     担当者
チーフ スーパバイザー      
スーパバイザー マネージャ
関連部署
  主管  
マネージャー 部門長 担当営業    
機器交換の
進捗報告
      担当者

連絡元 連絡先
SOC
運用担当者 随時対応 随時対応 随時対応
チーフ 15分 30分 4時間
スーパバイザー 30分 1時間 8時間
マネージャー 60分 便宜 便宜
機器交換の
進捗報告
60分毎 60分毎 60分毎

図2●連絡表の例(出典:インターネット セキュリティ システムズ)

 筆者がインシデント発生時の運用のポイントとして痛感しているのは、「第一報」の重要性だ。この第一報がどれだけ早く関係者に伝わるかが、その後の対応に大きく影響を及ぼす。障害発生時などは連絡よりも原因追求を優先してしまう場面を見かけるが、原因追求よりもまずは迅速な報告が優先されることを周知徹底しておくべきだろう。

SOC運用における心構え

 SOC運用に当たっての心構えには、立場によって「現場のエンジニアやオペレータの心構え」と「管理者の心構え」の2つがある。この2つが噛み合ってはじめて、成功するSOC運用環境が育つといえるのではないだろうか。

●現場のエンジニアやオペレータの心構え

 現場の心構えの中でも有名なのは「ヒヤリ・ハット」という言葉だろう。改めて言われるまでもなく、現場で運用にかかわる者は、日々「発見」「報告」「改善」という運用方式のスパイラルアップを行っていると思われる。その他に重要なポイントとして、SOC運用の現場で徹底されている2つの心構えを紹介したい。

 1つは「他人の仕事を疑え」ということだ。これは、特に専門性の高いサービスを提供している現場で発生する「ダブルチェック漏れ」という事故の大半を占める原因要素になっている。

 そもそもダブルチェックとは、他人の仕事を検証するという意味である。SOC運用の場合、1つの作業に2人が別々に取り掛かり、その結果が同じであればよしとする、という手法をとるが、作業の種類によっては他人の結果を別のエンジニアが検査するという工程があるのも事実だ。この場合に「他人の仕事を疑え」という心構えが重要になる。

 事故の事例を調査すると、「ベテランのA氏の仕事だったので信用してあまりしっかりとチェックをしなかった」とか「今までミスをしたことのないB氏の仕事だったので」という話をよく聞く。ダブルチェックが必要な工程では、「大丈夫だろう」ではなく「ミスがあるはずだ」と考える心構えを持つべきであろう。

 もう1つの心構えに、「安全を押しのけた速さは必要ない」というものがある。これは、特にSLAを導入しているサービス提供の現場で、最も大きいプレッシャーの1つだ。

 SLAは時間との勝負であり、決められた時間内に作業や通知を終わらせなければ違反となる。SLA違反を起こせば、違約金を支払わなければならないし、サービス品質が悪いと評価されてしまう。

 しかし、あまりにもSLAに縛られてダブルチェックを軽視したり、決められている手順を守らなかったりした結果、重大な事故を引き起こしてしまうケースは少なくない。たとえ顧客から「急げ」とプレッシャーをかけられても、スピードより安全を重視する心構えを持つべきであろう。これは、ITの世界だけでなく社会共通の心構えとしても重要な事柄ではないだろうか。

●管理者の心構え

 管理者の心構えにおいて重要な点は、運用現場では予期しない事故やミスが発生するという事実をしっかりと認識したうえで、ミスや事故を「無くす」ことを考えるのではなく「少なくしていく」と考えることではないだろうか。問題が発生することが問題なのではなく、問題を解決できないことが問題であると考える心構えを持つべきであろう。

 現場のエンジニアからの報告を良く聞き、問題の本質を見極める力も必要だ。ミスをしたエンジニアを叱るのではなく、ミスを報告したエンジニアを評価する環境を作るのも管理者の仕事である。

 問題の本質を考えるとき、経営的な視点から現状を分析すると非常に効果的な解決策が見つかる場合がある。SOC運用もビジネスであり利益を上げなければならない。一方で現場では、ミスが発生したのは人的リソースが不足しているのが原因だと主張する。

 では仮に、問題の本質を見極めることなく、現場からの要望にこたえて随時人的リソースを投入していけばどうなるだろうか。おそらくSOCビジネスは、利益の上がらない巨大なコストセンターになるだろう。ミスや事故が減るとも考えられない。サービスを受ける顧客も不安になるだろう。SOC従事者に十分な給与や賞与も支払えず、モチベーションは下がる一方だ。

 しかし、問題の本質はリソースが不足する「原因」にあると気付けば、たとえば運用支援システムの一部を改良するとか、2つの監視システムを統合するという具合に手立てが見つかるだろう。こうした施策の結果短期的にはコストが発生しても、中長期に見れば効果的な効率化ができる部分が確実にあるはずだ。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ