はじめに
システムを運用していると、多かれ少なかれインシデントが起きてしまうことがある。それはある程度は致し方ないこととして、会社としてはインシデント対応を行っていく。しかし、インシデント対応は「直せば終わり」ではない。IT全般統制の監査で問われるのは、直した後に何を、誰が、どう記録に残したかだ。
障害が起きて、誰かが気づいて、誰かが直す。ここまではどの現場でもできている。問題はその先である。誰が対応したか、誰が承認したか、なぜ起きたか、再発を防ぐために何を決めたか——この4つの記録が、復旧の速さと引き換えに抜け落ちる。
監査法人が見ているのは「障害が起きなかったか」ではなく「起きたときに体制が動いたか」であり、ここでつまずく現場を何度も見てきた。
そこで、本稿では、IT全般統制におけるインシデント対応について解説を行う。
インシデント管理とは何か：障害管理・問題管理との違い
インシデント管理とは、今起きている障害を止め、復旧させるための一連の対応を指す。
インシデント対応が終わったからヨシと終わらせるのではなく、インシデントの根本原因を特定し再発防止策を打つ活動が重要である。
実務で機能しているインシデント対応は、「発見→初動→事象・影響特定→回復→収束宣言→原因究明→対策検討→振り返り」という順序が基本である。
この順序でいうと、発見から収束宣言までがインシデント管理、原因究明から対策検討までが問題管理にあたる。ここを分けずに「直して終わり」にしてしまうと、問題管理のフェーズがまるごと抜け落ちてしまう。そのため、インシデント管理においては、適切な対応フローを構築することで、初動対応から反省までを振り返ることが重要になる。
監査で見つかる「やってはいけない」インシデント対応NGパターン
監査で指摘されるインシデント対応の不備の例3つを紹介していきます。なぜこれらの運用がダメなのかを理解していただくと幸いです。
対応記録を残さず口頭で終わらせる
Slackや口頭だけで対応が完結し、後から誰も経緯を追えないのはNGだ。その場にいた人しか経緯を知らないという属人化した状態が、統制上もっとも危ない。監査で「このインシデントの対応記録を見せてください」と言われて何も出せなければ、そもそも監査のやりようがなくなってしまうし、反省の後追いができない。
「直ったから終わり」で原因分析をしない
復旧はしたが、なぜ起きたかの反省を行っていないケースが有る。そのような会社は、何度も同じ種類の障害が繰り返し起きているのに、毎回その場しのぎの対応で終わっていることも珍しくない。監査人は復旧の速さ以上に「きちんと再発防止を出来るようなフローがあるのか」を必ず気にするのである。
誰が対応・承認したかが記録に残らない
本番環境に緊急でソースコードを変更したにもかかわらず、それを承認した人が記録に残っていないケースなどもある。それが常態化すると、「緊急だったから後で報告」が当たり前になってしまい、結局インシデント対応や変更内容が報告されないまま終わる可能性がでてしまう。
機能している体制は、インシデント責任者、作業者、レビュアー、責任主体という形などにインシデント対応者の役割を分けており、それぞれの役割を分離して対応している。この分離がないと、対応した人がそのまま自分を承認する状態になるなど、問題になることが多い。
IT統制上、監査で何が証跡として求められるか
監査で確認される証跡は、次の6つに整理できる。
- インシデント起票（いつ・何が・誰が気づいたか）
- 対応記録（誰が・いつ・何をしたか、時系列で）
- 承認記録（特に本番環境への変更を伴う場合）
- 原因分析と再発防止策の記録
- 重大度分類とエスカレーションルールの整備
- 社内報告体制の記録
このうち収束宣言は見落とされやすい。ここが曖昧だと、いつまでが緊急対応でいつからが平常運用かの区別がつかなくなる。また、原因究明で終わらせず、是正処置報告書のような形で対策の承認まで記録として残っているかも確認される。体制と記録だけでなく、対応メンバーへの教育や訓練の記録も、統制が実際に機能しているかを示す証跡として扱われる。
スタートアップの運用管理でよく見る甘さ
これはスタートアップあるあるなのだが、変更管理ツールや監視ツールを導入しているのに「証跡として使う」という発想がない現場が多いといえる。例えば、障害対応はSlackだけで完結していて、後から誰も追えない状態が常態化していたりする。これは、組織が大きくなってから、あるいはIPO準備に入ってから証跡不足に気づいて慌てるパターンを何度も見てきた。
きちんと運用できている現場ほど、レベル定義・役割分担・収束宣言までのルールを明確化して、インシデント管理体制が仕組み化されている。このような仕組みを適切に整備することで、IPOのための監査体制が整備されるだろう。
まとめ
- インシデント管理は「止めて直す」対応、問題管理は「原因を潰す」対応。この2つを分けて考える
- 監査で指摘される不備は「記録がない」「原因分析がない」「承認者が不明」「重大度の分類がない」の4パターンに集約される
- 証跡として残すべきは起票・対応記録・承認記録・原因分析・重大度分類・収束宣言の6点
- まずはインシデント起票と対応記録のテンプレを1つ作り、重大度を3段階程度で決めておく
- 「直ったら終わり」ではなく「記録が残って終わり」に意識を変えることが、監査対応の第一歩になる
関連記事
参考資料
- AXELOS「ITIL 4: Incident Management Practice Guide」（ITIL公式）
- 経済産業省「システム管理基準」（運用管理に関する部分）
- 日本公認会計士協会「IT委員会研究報告」（IT全般統制に関する部分）
