コラムセキュリティその他

インシデント訓練に参加して、インシデント発見と対応をやってみた！

投稿日 2025.02.28
セキュリティ訓練

学びのまとめ

今回のインシデント訓練を通じて、組織としての対応力を大幅に高めることができました。特に、属人化しない対応の重要性を再認識しました。これからもチーム一丸となって、より良い対応を目指していきます！

はじめに

この訓練には以下のメンバーが参加しました。

わかな（インシデント発見者、技術リーダー）
のりぴーさん（仕込み役、インシデント発生者）
あゆみさん（インシデントリーダー）
ひろかずさん（役員、今回は手が空いていない設定）

訓練の目的

規程に沿って組織としてインシデント対応できるようにする
インシデント対応を属人化しない

訓練の前提条件

Slack
- 事前に全社にSlackで連絡
Okta
- Token発行用のシステムアカウント作成
- カスタムロールセット作成
- 管理者権限のロールを付与
- 権限が問題ないTokenと超過したTokenを各1つ作成
Make Sandbox
- 権限超過したTokenを使ってOktaのユーザー情報を定期的に取得するジョブを作成

インシデント訓練の流れ

初動

訓練当日、私はOkta管理コンソールにログインしました。そこで、新規のTokenが発行されていることを発見しました。権限が超過している可能性を疑い、Slackで担当者を確認しました。のりぴーさんが対応を開始し、権限超過が判明しました。私はすぐにインシデントフローを開始しました。

一見Read Only AdminのAPIトークン

管理者ロールを見たらカスタムロールがついていた・・・！

Generalチャンネルで確認

権限超過を確認し対応スタート

エスカレーション後

インシデントがエスカレーションされると、ひろかずさんがあゆみさんをインシデントリーダーに選任しました。あゆみさんは報告書を作成し、時系列の記録を開始しました。あゆみさんは報告者である私と作業実施者ののりぴーさんにヒアリングを行い、インシデントの分類と通知を行いました。

ひろかずさんがあゆみさんをインシデントリーダーに選任
あゆみさんが報告書作成と時系列の記録を開始
報告者とのりぴーさんへのヒアリング実施
インシデントの分類と通知

参集と指示

技術リーダーとの調整が行われ、関係者と対応要員が参集しました。対応要員への説明が行われ、経緯と状況、インシデント重要度の見込み、調査・処置内容、記録や証跡の保管指示、重要度の確定、処置内容の意思決定、再発防止策の策定が行われました。

技術リーダーとの調整
関係者と対応要員の参集
対応要員への説明

過去のインシデント訓練におけるインシデントリーダー目線の記事がありますのでぜひ読んでみてください！
https://blog.cloudnative.co.jp/19911/

インシデントの解消

Oktaのログを確認し、APIの使用履歴を調査しました。また、makeコマンドの実行履歴を確認し、個人情報が流出していないか確認しました。その結果、問題がなかったため、権限超過のTokenを無効化しました。

Oktaのログを確認
makeの実行内容と履歴を確認
個人情報が含まれていないことを確認

後から気がついたのですが、以下の対応が漏れていました。

APIを発行したOktaアカウントの権限剥奪
makeのフローの停止

ふりかえり

訓練終了後、Notionのテンプレートをアップデートしながら振り返りを行いました。私の初動の動きの動画が残っていなかったため、次年度は最初から記録を残す方向で進めることにしました。また、Slackワークフローでの自動化案や、Oktaログに個人情報が含まれるかの判断基準を規定として作成することが議論されました。初動での混乱を防ぐための改善点として、APIトークンが2つあるはずが1つ目が期限切れで混乱したことが挙げられました。