3-4. インシデント対応 - 最初の30分で勝負が決まる

所要時間: 40-60分 ゴール: インシデント発生時の5フェーズを語れ、自分のサービスでの初動手順を文書化できる コミット内容: インシデントレスポンスプレイブック runbook.md とインシデントレポートテンプレを ~/learn/security/day34/ にコミット

前章とのつながり

このレッスンの位置づけ

Level 3 の4本目。これまでの章は 「事前 / 平時」 の話。本章はついに 「有事 = インシデント発生時」 の動き方。

3-3 ログと監視: 検知（気づく力）

本章 (3-4): 対応（気づいた後の動き）

次章 3-5 脅威モデリング: 事前予測（起きる前に予測する）

「平時の準備」が「有事の差」を生む。準備していないと、初動の30分でパニックして証拠を消したり、関係者通知を怠って法的問題を抱え込んだりする。

実害シーン: インシデント対応の良し悪しが企業の命運

Equifax (2017): 漏洩発覚後 6週間隠蔽、その間に役員が株売却 → 罰金 + 経営陣総辞任 → 対応の悪さで2倍の制裁

Knight Capital (2012): トレーディングシステムのデプロイミスで 45分で4.6億ドル損失、会社事実上倒産 → 初動失敗の極端例

GitLab (2017): 本番DB誤削除を その日のうちに全公開、ライブストリーミングで復旧 → 信頼が 逆に上がった 模範事例

「事故そのもの」より「事故後の振る舞い」で評価される。準備の差が運命を分ける。

大前提: なぜインシデント対応を学ぶか

セキュリティインシデントは**「もし起きたら」ではなく「いつ起きるか」**。完璧な防御は存在しない。Google や Microsoft でも年に何件か小さなインシデントが発生している。重要なのは「起きた時にいかに早く・正しく対応できるか」。

実例:

GitLab 2017年1月のDB全削除: SREエンジニアが本番DB上で rm -rf し、6時間分のデータを失った。その日のうちに事象・原因・対応を全て公開し、ライブストリーミングで復旧作業を見せる前代未聞の対応。技術力ではなく透明性とコミュニケーションでむしろ信頼を上げた。
Cloudflare 2019年7月の全サービス停止: 1行の正規表現で CPU 100% → 全世界のサイトが502。30分以内に切り戻し、当日中に詳細ポストモーテム公開。
Equifax (2017): 1.4億人の個人情報漏洩。問題はパッチ未適用の Apache Struts。発覚後の対応も最悪（漏洩を内部知ってから6週間後に公開、その間に役員が株売却）。CEO 含む経営陣が引責辞任。ポストモーテム文化の対極。
AWS S3 outage (2017): 1人のエンジニアのタイポでスクリプトが多くのサーバーを誤って落とした。原因を詳細に説明し再発防止策を公開。AWS の事後説明の優等生事例。
Knight Capital (2012): トレーディングシステムのデプロイミスで45分間に4億6千万ドル損失、会社が事実上倒産。インシデント対応失敗の極端な例。

良いインシデント対応の共通点:

早期検知 - ログ・監視がしっかりしている
冷静な初動 - パニックで悪化させない
明確な役割分担 - 誰が何を決めるか事前に決まっている
正直なコミュニケーション - 隠さない、誇張しない、推測を事実と混ぜない
ポストモーテム - 責めない、学ぶ

このレッスンで「起きた時にやるべきこと」を体系化する。

セッション①: 5フェーズと最初の30分（25-30分）

1. インシデント対応の5フェーズ

┌─────────┐  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
│ 1. 検知  │→│2. 封じ │→│3. 根絶 │→│4. 復旧 │→│5. 学習 │
│ Detect  │  │  込め  │  │Eradicate│  │Recover │  │ Learn  │
└─────────┘  │Contain │  └────────┘  └────────┘  └────────┘
             └────────┘

NIST SP 800-61 という米国NIST の公式ガイドラインがベース。世界中の組織がこれに従う。

フェーズ	やること	失敗パターン
1. 検知	攻撃・異常に気付く	監視ない、アラート見ない、ユーザー報告で初めて知る
2. 封じ込め	拡大を止める	パニック、勝手に色々止めて証拠破壊
3. 根絶	原因を取り除く	表面的な対応で再侵入される
4. 復旧	サービスを戻す	バックアップから戻して元の脆弱性も復活
5. 学習	再発防止	「個人ミスでした」で終わる

2. 最初の30分でやるべきこと

「インシデント検知！」となった瞬間からの1800秒が最も重要。

分 0-5  : 状況把握、関係者招集
分 5-10 : 影響範囲の暫定推定
分 10-20: 封じ込め判断と実行
分 20-30: 関係者への第一報、証跡確保開始

0-5分: 状況把握と招集

最初に答えるべき問い
何が起きているか: アラート文言、検知ソース

本物か誤検知か: 過去の False Positive 履歴

影響の規模感: ユーザー単位？データ単位？サービス単位？

進行中か終わったことか: 攻撃が今も続いている？

誰を呼ぶか: オンコール、上司、セキュリティチーム

Slack や PagerDuty で 専用インシデントチャネル を即立てる:
#incident-2026-05-14-01-data-leak-suspected
ここに全てを集約。事後の調査・記録にもなる。

5-10分: 影響範囲の暫定推定

影響範囲の見立て

どのシステム: API か DB か WAF か LB か

どの期間: いつから？（攻撃開始時刻、検知時刻、現在）

何ユーザー: 数十人？数百万人？特定セグメント？

どのデータ: 個人情報？決済情報？機密文書？

推測を事実と混ぜない。「DB から N 件取られた可能性がある」と「N 件取られた」は天と地。

10-20分: 封じ込め判断

封じ込めにはトレードオフ。

アクション	メリット	デメリット
該当サーバー停止	拡大を即停止	サービス停止、メモリ上の証拠喪失
ネットワーク切断	攻撃継続を防ぐ	攻撃者の動作証拠喪失
アカウント無効化	攻撃者の権限剥奪	攻撃者に気付かれる
監視継続	攻撃の全貌を把握	被害拡大の可能性
WAF/CDN ルール追加	攻撃トラフィックを遮断	正規ユーザー影響可能性

封じ込めの2つの戦略

即時封じ込め (Containment): 攻撃を即止める。被害拡大防止優先。一般的に推奨

観察封じ込め (Honeypot 戦略): あえて泳がせて手口を全把握。法執行機関が来る大規模事案の手法

普通の企業は即時封じ込め一択。観察戦略はFBIなどと連携する大規模インシデントの世界。

20-30分: 第一報と証跡確保

第一報のコミュニケーション

関係者への最初の連絡は内容より速度が重要。

テンプレ:

件名: [INCIDENT] サービスXで認証突破の疑い、調査中

## 現在の状況（HH:MM 時点）
- HH:MM に異常な認証ログを検知
- 影響: 未確定（最大で全ユーザー想定）
- 攻撃継続: 不明（封じ込め判断中）

## 対応中
- インシデントチャネル #incident-xxx で対応中
- 担当: @alice (リード), @bob (技術), @charlie (広報待機)

## 次回更新
30分後、または重大変化があり次第

## 連絡先
緊急: @alice (電話)

3. 役割分担（インシデントコマンダー方式）

NASA や Google SRE で使われるインシデント指揮の方法。

┌─────────────────────────────────┐
│  Incident Commander (IC)        │ ← 全体指揮、意思決定、コミュニケーション
└─────────────────────────────────┘
        ↓ 指示
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Operations   │ │ Communications│ │ Planning     │
│ Lead         │ │ Lead         │ │ Lead         │
│ 技術対応     │ │ 内外通知     │ │ 影響調査     │
└──────────────┘ └──────────────┘ └──────────────┘

なぜ役割を分けるか

パニック状態では人は同時に複数のことができない。「指揮、技術対応、広報、社内連絡」全部1人だと全部中途半端になる。

IC（インシデントコマンダー）: 技術判断はしない、全体を見て決断する人。意思決定の最終責任

Operations Lead: 実際にコマンドを打つ。証跡を残しながら作業

Communications Lead: 経営層・ユーザー・取引先・規制当局への通知

Planning Lead: ホワイトボード係。「何が分かっていて、何を調べているか」を整理

規模が小さければ1人で複数兼任可能だが、役割を明示することが重要。「誰が決めるか」が明確だと判断が速い。

4. 証跡確保 - フォレンジックの基本

侵入された証拠は時間とともに失われる。電源を切ればメモリ上のデータ消失、ファイルを編集すれば改ざん。「触らずに記録する」が原則。

# 1. メモリダンプ（プロセス情報、ネット接続）
ps auxf > /tmp/forensic_ps.txt
netstat -anp > /tmp/forensic_netstat.txt
ss -anp > /tmp/forensic_ss.txt
lsof > /tmp/forensic_lsof.txt
last > /tmp/forensic_last.txt
w > /tmp/forensic_w.txt
who > /tmp/forensic_who.txt
 
# 2. ログのスナップショット（圧縮で保全）
sudo tar czf /tmp/forensic_logs_$(date +%Y%m%d_%H%M%S).tar.gz \
    /var/log/auth.log* \
    /var/log/syslog* \
    /var/log/nginx/ \
    /var/log/audit/
 
# 3. ハッシュで完全性証明
sha256sum /tmp/forensic_logs_*.tar.gz > /tmp/forensic_hash.txt
 
# 4. 別のサーバーへ即時転送
scp /tmp/forensic_* forensic-storage:/secure/$(hostname)/

証跡確保の鉄則「Chain of Custody」

法執行機関や訴訟で証拠を使うには「証拠の鎖」が必要:

誰が取得したか

いつ取得したか

どこから 取得したか

どう保管 したか

改ざんされていない ことの証明（ハッシュ）

これが切れると証拠能力ゼロ。少なくとも社内調査でも「何を見たか」を記録しないと事実関係が後で揉める。

やってはいけないこと

侵入サーバーで vim でログ編集: ファイル更新日時が変わって証拠破壊

「とりあえずサーバー再起動」: メモリ上のマルウェアプロセス、現在の接続情報が消える

rm で疑わしいファイル削除: マルウェアサンプル喪失、攻撃手口分析不可

正規ユーザーの操作を「攻撃」と誤認: 「Alice が変なコマンド打ってる」→ 実は監査担当者だった事例も

Slack に IP アドレス・ハッシュを長文で投稿: ログツールには情報が偏在し探しづらい

証跡確保チェックリスト

□ プロセス一覧スナップショット
□ ネットワーク接続スナップショット
□ 直近24時間のログ全部
□ /tmp /var/tmp /dev/shm の中身
□ 各ユーザーのbash_history、zsh_history
□ crontab 設定（怪しい cron 仕込まれることがある）
□ /etc/passwd, /etc/shadow（新規アカウント作られてないか）
□ ファイルシステムのタイムライン（find / -mtime -7）
□ メモリダンプ（必要なら）

セッション②: インシデントタイプ別対応と法的義務（20-30分）

5. シークレット漏洩

GitHub にAPIキーが push された、ログにトークンが流れた、退職者がパスワードを持ち出した、など。

対応手順:

1. 該当シークレットを即座にローテーション
   - DB パスワード変更
   - APIキー再発行
   - JWT 署名鍵ローテーション + 全セッション無効化
 
2. 漏洩したシークレットの使用ログを全期間調査
   - そのキーで何にアクセスされたか
   - 不審な API 呼び出しがあったか
 
3. 漏洩したシークレットの「子孫」も無効化
   - そのキーで取得した別のトークン
   - そのキーで作成したデータ
 
4. 漏洩経路の根絶
   - GitHub なら commit 履歴から削除（BFG Repo-Cleaner）
   - ログなら集約サーバーから検索・削除

GitHub に push されたシークレットの怖さ

push した瞬間にbot がスキャンする。AWS のクレデンシャル、Stripe のキーなど、有名どころは「5分以内に悪用される」。

実例: GitHub の public-leaked-secrets という研究で、新規commitに含まれたAWS秘密鍵が平均4分で悪用された。

対策:

git-secrets, trufflehog, gitleaks で pre-commit hook

GitHub Push Protection（push 時点でブロック）

AWS は GitHub と連携して漏洩キーを自動失効する仕組みがある

6. DDoS 攻撃

症状: 突然のトラフィック爆増、サーバーが応答しない、CPU 100%
対応:
  1. CDN / WAF の DDoS 防御モード ON
     - Cloudflare の "Under Attack Mode"
     - AWS Shield Advanced
  2. レート制限を強化
     - nginx limit_req_zone
     - WAF のルール追加
  3. オートスケール上限を一時的に上げる
  4. 静的コンテンツへ切り替え（メンテページ）
  5. 攻撃元 IP を全 ban（fail2ban + WAF）

DDoS は防ぐより緩和

完全に防ぐのは無理。「サービス継続できる範囲に抑える」が現実解。

規模感:

〜10Gbps: 自前で対応可能（高品質回線）

10〜100Gbps: CDN/Cloud WAF が必要（Cloudflare 無料プランで対応可）

100Gbps〜: 商用 DDoS 対策ベンダー（Akamai, Cloudflare Pro）

1Tbps〜: 国家レベル、専用契約必須

7. ランサムウェア

症状: ファイルが暗号化されている、金銭要求のメッセージ
対応:
  1. 即座に被害PC・サーバーをネットワーク隔離（ケーブル抜く）
  2. 他システムへの感染拡大確認
  3. バックアップから復旧
     - バックアップ自体が暗号化されていないか確認
     - オフライン/イミュータブルバックアップが理想
  4. 身代金は払わない（FBI推奨）
     - 払っても復号化されない、再襲撃される
  5. 法執行機関に通報

ランサムウェアは「バックアップ戦略」がほぼ全て

3-2-1 ルール:

3: データのコピーを3つ持つ

2: 2種類の異なるメディアに保存

1: 1つはオフサイト（または完全オフライン）

イミュータブルバックアップ（書き換え不可ストレージ、S3 Object Lock、WORM）が現代のスタンダード。**ランサムウェアは「バックアップを暗号化してから本体を暗号化する」**ので、書き換え不可でないと意味なし。

8. 内部犯行

症状: 退職予定者が大量データダウンロード、深夜の管理操作
対応:
  1. 該当アカウント即時無効化（パスワード変更 + セッション破棄）
  2. 物理的アクセスも遮断（ID カード、VPN）
  3. ログから行動全部洗い出し
  4. HR・法務と連携
  5. データの持ち出し範囲を特定
  6. 必要なら法的措置（不正アクセス防止法、営業秘密窃取）

退職時の典型リスク

退職決定〜退職日の間に持ち出し が最も多い

「まだログイン権限がある」状態で 「もう会社のものを大事にしない」心理

対策:

退職予告から退職日までモニタリング強化

重要データへのアクセスログ精査

退職日には当日のうちに全権限剥奪（Slack、Email、SSO、VPN、SaaS全部）

SSO 一元管理されていればワンストップで剥奪可能

9. 法的義務 - 通知義務

規制	適用	通知期限
個人情報保護法（日本）	日本居住者の個人情報	速やかに本人通知、個人情報保護委員会へ報告
GDPR（EU）	EU居住者の個人データ	発覚から72時間以内に監督機関、影響大ならユーザーにも
CCPA（カリフォルニア）	カリフォルニア州民	不当な遅滞なく
PCI DSS	決済カード情報	加盟店契約に基づき即時、フォレンジック必須
HIPAA（米国医療）	米国の医療データ	60日以内

GDPR の72時間ルールは超重要

EU 居住者のデータが含まれていたら 発覚から72時間以内 に通知。違反すると 全世界売上の4%または2000万ユーロのいずれか高い方 の罰金。

実例:

British Airways: 2018年漏洩で2020年に 2000万ポンド の罰金

Marriott: 5億人漏洩で 1800万ポンド の罰金

72時間以内 = 金曜深夜に発覚 → 月曜午前までに監督機関通知。週末関係なし。

通知遅延の被害

Uber は2016年に漏洩を1年隠蔽 → 2017年発覚時に各国規制当局から重罪扱い → 当時のCSOが訴追され有罪判決（米国初の事例）。

隠す方が高くつく。事案発生時に「公表するか」で迷ったら公表側に倒すのが現代の鉄則。

10. ポストモーテム - 責めない、学ぶ

ポストモーテム（postmortem） = 「死後解剖」。インシデント終息後の振り返り。

Blameless Postmortem（責任追及型ではない）
Google SRE の文化として確立。

思想: 「人間のミス」は原因ではなく症状。本質的な原因はシステム・プロセス・設計にある。
NG: 「Alice が誤って本番DBで rm したから」
OK: 「本番DBで簡単に rm できる権限設計だった」
    「本番と開発のプロンプトが見分けにくかった」
    「危険コマンドの2段確認がなかった」
個人を責めると 「次から隠す」 文化になる。隠されたら学習機会喪失。安全に失敗を共有できる組織が長期的に強い。

ポストモーテムテンプレート

# ポストモーテム: <インシデント名>
 
## 概要
- 発生日時: 2026-05-14 03:14 JST
- 検知時刻: 03:18 (アラート)
- 復旧時刻: 04:32
- 影響: ユーザーログイン不可、推定2.3万人影響
- Severity: P1
- 担当: alice (IC), bob (技術), charlie (広報)
 
## タイムライン
| 時刻 | 出来事 |
|---|---|
| 03:14 | 攻撃トラフィック開始（事後判明） |
| 03:18 | アラート発火 |
| 03:20 | オンコールが応答、インシデントチャネル作成 |
| 03:35 | 影響範囲特定: ログイン API のみ |
| 03:50 | WAF ルール追加で攻撃遮断 |
| 04:32 | サービス正常化確認 |
 
## 根本原因
（技術的に何が起きたか。人を責めず、システムを語る）
 
## 何がうまくいったか
- アラート発火が4分以内
- インシデント手順書通り対応できた
- ユーザー通知が早かった
 
## 何がうまくいかなかったか
- 攻撃開始4分後の検知は遅い
- WAF ルール変更に手動承認が必要で時間ロス
- 第一報のテンプレが古かった
 
## アクションアイテム
| # | 内容 | 担当 | 期日 |
|---|---|---|---|
| 1 | 検知ルールの感度を上げる | alice | 2週間 |
| 2 | WAF ルール変更の自動化 | bob | 1ヶ月 |
| 3 | 通知テンプレ更新 | charlie | 1週間 |
 
## 学習事項
- 攻撃者のIPレンジが特定のクラウドプロバイダから集中
- 既存検知ルールは「単純なブルートフォース」前提で、分散攻撃に弱かった

アンチパターン: ポストモーテム文化なし

「個人ミスでした」で終わる

同じインシデントが繰り返す

誰も失敗を共有しない、隠す

次世代に知見が継承されない

練習課題: 自分のサービスのインシデント Runbook を書く

自分が作った（or 想定する）Webアプリに対し、以下のテンプレで Runbook を作成:

# インシデントレスポンス Runbook: <サービス名>
 
## 連絡網
- オンコールエンジニア: @alice (Phone: xxx)
- 上司・経営層: @ceo
- 広報: @comms
- 法務: @legal
- 外部: クラウドベンダー、CDN ベンダー、外部セキュリティベンダー
 
## エスカレーション基準
- P0（即時）: 個人情報漏洩、サービス完全停止、決済不可
- P1（1時間）: 一部機能停止、攻撃進行中
- P2（営業時間内）: パフォーマンス劣化、軽微な脆弱性
 
## 初動チェックリスト（最初の30分）
- [ ] インシデントチャネル作成
- [ ] IC, Operations, Communications 配置
- [ ] 状況把握: 何が・いつから・どの範囲・進行中か
- [ ] 証跡確保: ログスナップショット、メモリダンプ
- [ ] 第一報: 経営層、関係者へ
- [ ] 封じ込め判断と実行
 
## タイプ別初動
 
### 認証突破疑い
1. 該当ユーザーセッション無効化
2. パスワードリセット強制
3. auth.log 解析、攻撃元IP特定
4. fail2ban / WAF で遮断
 
### DDoS
1. Cloudflare Under Attack Mode ON
2. オートスケール上限引き上げ
3. レート制限強化
4. 攻撃継続なら CDN サポートへ連絡
 
### データ漏洩疑い
1. アクセスログ精査（誰が・何を・いつ）
2. 影響範囲確定
3. 法務・広報を即招集
4. 通知義務（GDPR/個人情報保護法）の判断
5. 必要なら72時間以内に監督機関通知
 
### シークレット漏洩
1. 該当キー即ローテーション
2. そのキーで作られた子データも無効化
3. 漏洩経路調査
4. git 履歴から削除（pushされていた場合）
 
## 通知テンプレ
（第一報、続報、最終報告のテンプレ）
 
## ポストモーテム手順
1. インシデント終息後72時間以内に開催
2. Blameless で実施
3. アクションアイテムを JIRA / GitHub Issues 化
4. 公開可能ならブログで共有

これを ~/learn/security/day34/runbook.md として書く。実際のインシデントが起きた時、これが命綱になる。

業界事例: GitLab 2017年 DB全削除

何が起きたか: 2017年1月31日深夜、GitLab のSREエンジニアが本番DBレプリケーション復旧作業中、誤って本番マスターで rm -rf を実行。300GB のデータが消失。

対応の見事さ:

即座に Twitter で公表
YouTube ライブストリーミングで復旧作業を全世界に公開
ステータスページに詳細な状況を時々刻々更新
全てのバックアップが機能していないことを発覚しても隠さなかった（5種類のバックアップのうち、復旧に使えたのは1つだけ。残り4つは設定ミスや古いデータで使えなかった）
結果として6時間分のデータロスト

ポストモーテムから学ばれたこと:

バックアップは「取れている」だけでなく「戻せる」かを検証すべき
本番作業時のプロンプト（hostname の色分け、確認画面）の重要性
疲労状態（深夜・休日）での重要操作を避ける運用設計

最終的に: GitLab はこの透明性で信頼を上げた。技術的失敗を学習機会として共有した姿勢が業界の模範となった。

締め: git で証跡を残す

cd ~/learn/security/day34
git add runbook.md postmortem_template.md
git commit -m "feat(security): インシデントレスポンスRunbookとポストモーテムテンプレ"

チェックリスト

インシデント対応の5フェーズを語れる
最初の30分で何をすべきか箇条書きできる
インシデントコマンダー方式の役割分担を理解した
証跡確保の手順とNG行動を即答できる
GDPR 72時間ルールを知っている
シークレット漏洩、DDoS、ランサムウェア、内部犯行の各初動を語れる
Blameless Postmortem の思想を説明できる
自分のサービス用 Runbook を1つ書いた

詰まった時のチートシート

場面	やること
アラート発火	インシデントチャネル作成、IC配置
影響範囲不明	「最大ケース」で想定し縮小していく
封じ込めか観察か	即時封じ込め原則
証跡確保	`ps`, `netstat`, `lsof`, ログtar
攻撃継続中	WAF/CDN ルール追加、レート制限
シークレット漏洩	即ローテ、子トークン無効化
個人情報漏洩	法務・広報招集、72時間ルール確認
終息後	Blameless Postmortem

「実務OK」基準

インシデント発生時、最初の3分で何をするか即答できる
証跡を「触らずに」保存する手順を実行できる
GDPR 72時間ルール等の法的義務を把握している
ポストモーテムを Blameless で書ける
Runbook を自分のサービス用に書ける
「攻撃を受けている」状況でパニックにならず、冷静に手順を踏める

さらに深掘りするなら

公式: NIST SP 800-61 (Computer Security Incident Handling Guide)
公式: GDPR 公式ガイダンス
書籍: 『Site Reliability Engineering』Google - 第14章インシデント管理
書籍: 『The Phoenix Project』Gene Kim - DevOps とインシデント対応の物語
事例: GitLab DB Loss Postmortem
事例: Cloudflare の各種ポストモーテム
ツール: PagerDuty / Opsgenie（オンコール管理）、Statuspage（ステータス公開）

メタ認知: 自分の理解度を診断する

30秒セルフテスト

インシデント対応の5フェーズを順に

発覚直後の 最初の30分 でやるべき3つ

証跡保全 で絶対にやってはいけないこと

GDPR の 72時間ルール とは？

Blameless Postmortem の本質を1文で

詰まったら → 5フェーズと初動30分の章を再読、Runbook テンプレを写経。

次のレッスン

3-5 脅威モデリングで「脅威モデリング」を扱う。インシデント対応は事後、脅威モデリングは事前。設計段階で「何が起きうるか」を考える力を身につける。STRIDE フレームワークを使って体系的に。

間隔反復ポイント

Runbook は 「書いて終わり」になりがち。半年に1度、机上演習（テーブルトップ）でシナリオを走らせて Runbook の漏れを確認する。やっておくと、いざ本番で動ける。

バックエンドマスター

エクスプローラー

3-4_インシデント対応

3-4. インシデント対応 - 最初の30分で勝負が決まる

前章とのつながり

大前提: なぜインシデント対応を学ぶか

セッション①: 5フェーズと最初の30分（25-30分）

1. インシデント対応の5フェーズ

2. 最初の30分でやるべきこと

0-5分: 状況把握と招集

5-10分: 影響範囲の暫定推定

10-20分: 封じ込め判断

20-30分: 第一報と証跡確保

3. 役割分担（インシデントコマンダー方式）

4. 証跡確保 - フォレンジックの基本

セッション②: インシデントタイプ別対応と法的義務（20-30分）

5. シークレット漏洩

6. DDoS 攻撃

7. ランサムウェア

8. 内部犯行

9. 法的義務 - 通知義務

10. ポストモーテム - 責めない、学ぶ

練習課題: 自分のサービスのインシデント Runbook を書く

業界事例: GitLab 2017年 DB全削除

締め: git で証跡を残す

チェックリスト

詰まった時のチートシート

「実務OK」基準

さらに深掘りするなら

メタ認知: 自分の理解度を診断する

次のレッスン

グラフビュー

目次

バックリンク